Logiciel de gestion de copropriété : d'un cahier des charges de centaines de points à un plan de sprints

Sur la table, il y a un cahier des charges technique de plusieurs centaines de points. De la gestion des demandes à l'appel de charges, de l'enregistrement des visiteurs à la reconnaissance de plaques d'immatriculation, de l'assistant d'intelligence artificielle à la gestion des catastrophes et des situations d'urgence : 13 grandes rubriques et des dizaines d'exigences détaillées. Tout est important, tout sera un jour en production. Dans un projet qui démarre avec un tel document, il y a deux pièges : essayer de tout faire en même temps, ou perdre des mois dans le débat sur les priorités.

Dans le Logiciel de gestion de copropriété, notre première tâche n'a pas été d'écrire du code, mais de transformer ce document en un plan exécutable.

Le projet en bref

Le Logiciel de gestion de copropriété est la plateforme opérationnelle que nous avons développée pour un client qui gère, au sein d'une même structure d'entreprise, un grand nombre de résidences très différentes les unes des autres. Elle se compose d'un panneau d'administration web et d'applications mobiles pour les résidents, le terrain et les gestionnaires. Les modules de demandes et de réclamations, de pannes, de maintenance et d'ordres de travail, de charges et de finances, de réservation des espaces communs, de visiteurs, de colis, d'annonces, d'inventaire et de compteurs reposent sur le même socle de données. Les systèmes externes tels que l'ERP et la comptabilité, le POS bancaire, la facture électronique, les SMS, les compteurs IoT et la reconnaissance de plaques d'immatriculation se raccordent par une couche d'intégration distincte.

Du point du cahier des charges au critère d'acceptation

Dans un premier temps, nous avons réparti le cahier des charges en huit groupes de modules centraux : identité et droits d'accès ; résidence, bâtiment et structure physique ; demandes et réclamations ; visiteurs et invités ; services aux résidents ; communication et notifications ; fondations mobile et panneau ; infrastructure technique et sécurité. Nous avons ensuite découpé chaque groupe en sous-modules et rédigé, pour chacun, un document sur le même modèle :

• Le point du cahier des charges auquel il correspond et la phase dans laquelle il se place,
• Les règles métier, les scénarios principaux et les exceptions,
• Les champs de données, les besoins d'écran et les dépendances,
• Les critères d'acceptation, les points ouverts et les hypothèses.

Ces documents se sont transformés en lots de travail organisés par sprint. Chaque point du cahier des charges a été rattaché à un document de module, et chaque module à un lot de sprint ; les contrôles d'acceptation ont été réalisés le long de cette chaîne. La réponse à la question de savoir pourquoi un écran existe ou d'où vient une règle était toujours un numéro de point.

L'ordre des sprints de la première phase reflétait lui aussi cette logique : d'abord la base technique et le modèle d'identité, puis l'ossature de la structure physique, les interfaces d'accès du panneau et du mobile, le flux des demandes et les notifications, les services aux visiteurs et aux résidents ; et enfin le durcissement de la couche de sécurité, d'audit et d'autorisations, ainsi que la préparation de l'acceptation.

Laisser chaque phase prête pour la suivante

Nous avons établi un plan en trois phases. Lors de la première, l'identité, les droits d'accès, la structure physique, les demandes et les services aux résidents ont été mis en production ; lors de la deuxième, les finances, les charges, la maintenance, les réservations et le mobile terrain ont été ajoutés ; lors de la troisième, la plateforme a été complétée par des modules avancés tels que l'IoT, le contrôle d'accès, la gestion du personnel et des plannings d'équipes, et un assistant d'intelligence artificielle. Chaque phase a été mise en service avec ses propres critères d'acceptation, et la suivante a été construite sur le même socle.

L'un des éléments les plus utiles du plan était la liste des « domaines hors phase mais dépendants » figurant dans le document de chaque phase. Lors de la première phase, les systèmes de contrôle d'accès dépendant du matériel, le flux complet des intégrations financières et les données de compteurs n'étaient pas livrés ; mais le modèle de données et l'architecture ont été construits en tenant compte de ces domaines. Lorsque la reconnaissance de plaques d'immatriculation est arrivée lors de la troisième phase, la base qui associe les informations du véhicule à la structure physique était en place depuis la première phase.

Nous avons appliqué la même logique aux systèmes externes. La banque, la facture électronique, l'ERP, la reconnaissance de plaques d'immatriculation et les compteurs entraient en service selon des calendriers différents. Comme nous avons raccordé les intégrations par une couche d'adaptateurs distincte, qui ne touche pas aux règles métier, le retard d'une intégration n'a pas retardé le produit. Les clés d'API et l'état des services sont eux aussi gérés depuis le panneau ; pour chaque connexion, comme la banque ou l'ERP, la clé propre, les résidences et les périmètres où elle est utilisée figurent dans l'enregistrement.

La sécurité dès la base, les distinctions par écrit

La matrice rôles-permissions, les journaux d'audit, la gestion des consentements KVKK (loi turque sur la protection des données personnelles) et la gestion des clés d'API n'ont pas été repoussées à plus tard ; elles ont été mises en service dans le cadre de la première phase. C'est dans la conception des droits d'accès que nous avons le plus mesuré l'intérêt d'avoir rédigé les règles métier avec autant de détail dans les documents. Une même personne peut être copropriétaire dans une résidence, locataire ou consultant dans une autre. L'utilisateur a donc été conservé sous la forme d'un enregistrement unique ; les droits ont été attribués par rôle, via le rattachement à la résidence. Les équipes de demandes et les équipes d'intervention ont elles aussi été définies indépendamment l'une de l'autre.

Une distinction inscrite dans le document a en outre fermé dès le départ une faille qui aurait pu apparaître plus tard : le type d'enregistrement et le rôle applicatif ne sont pas la même chose. Choisir l'étiquette « consultant » dans le formulaire d'enregistrement ne donne à personne de droits sur une résidence ; les droits ne s'ouvrent que par le rôle ajouté au rattachement à la résidence. Des risques comme celui d'une étiquette qui ouvre silencieusement des droits ne deviennent visibles que lorsqu'une telle distinction est mise par écrit.

Ce que nous avons appris sur le terrain

• Ne réduisez pas le cahier des charges, rendez-le traçable. Plutôt que de réduire le périmètre, rattacher chaque point à un document et à un lot de sprint a fait de la hiérarchisation des priorités autre chose qu'un débat.
• Le critère d'acceptation s'écrit au début du travail. Savoir dès le départ ce qui sera considéré comme terminé, et quand, a permis de mettre chaque phase en production avec sa propre acceptation.
• Concevez dès aujourd'hui ce que vous ne ferez pas aujourd'hui. Tenir compte dans le modèle de données des domaines hors phase mais dépendants a permis de construire les phases suivantes sur le même socle.
• Le calendrier des intégrations ne doit pas être celui du produit. La couche d'adaptateurs n'a pas transformé le retard des systèmes externes en retard du produit.

Un grand cahier des charges n'est pas un obstacle ; bien lu, c'est la feuille de route la plus détaillée. Il suffit que chaque point ait une phase, un document et un critère d'acceptation.

En quel plan votre cahier des charges peut-il se transformer ?

Si vous vous apprêtez à démarrer avec un cahier des charges de large périmètre, ou si vous ne savez pas par où commencer avec les exigences dont vous disposez, nous pouvons travailler avec vous dès la phase de planification. Sur la page du projet Logiciel de gestion de copropriété, vous pouvez examiner les modules et planifier un échange avec nous depuis notre page de contact.