Rentapp
Rentapp est un prototype d’application de paiement des loyers, destiné à des locataires et à des propriétaires, dont le développement s’est interrompu en 2022 avant l’intégration d’un prestataire de paiement.
- Rôle
- Auteur de l’API ; application mobile développée avec un second contributeur
- Période
- De février à octobre 2022
- État
- Prototype. Prototype inachevé, paiement simulé
- Technologies
- Django 3.2, Django REST Framework, PostgreSQL, Flutter, flutter_bloc
- Dépôts
- Deux
Contexte
Rentapp devait permettre à un locataire de régler son loyer depuis son téléphone, par carte bancaire ou par argent mobile, et à un propriétaire de suivre les règlements de ses résidences. Le serveur modélise à cette fin les propriétaires, les résidences, les locataires, les baux, les échéances mensuelles et les paiements, tandis que l’application de 2022 proposait au locataire une vue de ses mois, une feuille de paiement et un reçu.
Le projet a connu deux remaniements successifs et n’a jamais été relié à un prestataire de paiement. Il m’a semblé préférable de le présenter pour ce qu’il est, à savoir un prototype dont certains choix de modélisation méritent d’être conservés.
Problème
Un bail produit une échéance par mois, et la solution habituelle consiste à les créer par une tâche planifiée, ce qui suppose un ordonnanceur à déployer et à surveiller pour un prototype qui n’en avait pas d’autre usage. Il fallait par ailleurs pouvoir dire sans ambiguïté si une échéance était réglée, et par quel moyen, et identifier un locataire par son numéro de téléphone plutôt que par une adresse électronique.
Réponse apportée
Des échéances générées à la lecture
Les échéances ne sont créées par aucune tâche de fond. Lorsqu’un locataire consulte ce qu’il doit, le bail parcourt les mois écoulés depuis sa création et crée l’échéance de chaque mois qui n’en possède pas encore, au montant du loyer.
def generate_due_payments(self):
months = Util.months_between(self.created_at.date(), datetime.date.today())
for month in months:
PaymentDue.objects.get_or_create(due_date__month=month.month, due_date__year=month.year,
defaults={
'contract': self,
'label': "Due",
'amount': self.rent,
'due_date': month,
})Un paiement rattaché à son instrument
Une échéance est réglée lorsqu’elle pointe vers un paiement, et l’arriéré d’un locataire se déduit de la somme des échéances qui n’en ont pas. Le paiement porte une référence unique et une contrainte de base de données lui impose de désigner une carte ou un compte d’argent mobile, si bien qu’aucun règlement ne peut être enregistré sans son moyen. Le reçu était quant à lui produit sur le téléphone, sous la forme d’un PDF muni d’un code QR.
Téléphone, code à usage unique et code PIN
La connexion par nom d’utilisateur et mot de passe a été remplacée en août 2022 par un parcours en trois temps : le numéro de téléphone et l’identifiant de l’appareil, un code à usage unique valable deux minutes, puis un code PIN choisi à l’inscription. L’inscription exige une validation récente du code, le même appareil et l’acceptation des conditions.
Limites et perspectives
Le paiement est simulé de bout en bout, aucun prestataire n’étant intégré, et aucune passerelle n’envoie le code à usage unique, que le serveur ne renvoie qu’en environnement de développement. L’extrait ci-dessus comporte de surcroît un défaut : la recherche d’une échéance existante ne porte que sur le mois et l’année, et non sur le bail, de sorte que deux baux partageraient la même échéance.
Le remaniement de la connexion a enfin désactivé les routes métier de l’API, que l’application continuait d’appeler lorsque le travail s’est arrêté ; les deux dépôts ne sont donc plus alignés. Les tests sont restés à l’état d’ébauches. L’application mobile a été ramenée en avril 2026 à un simple écran d’accueil, et une reprise du projet devrait repartir du modèle de données plutôt que du code existant.