Dans Death Note, le carnet est accompagné de règles. Beaucoup de règles. Le manga passe des chapitres entiers à les énumérer, à les préciser, à révéler des cas particuliers. Et l'intrigue entière repose sur leur exactitude : un détail mal compris et tout le plan s'écroule.
C'est la meilleure description que je connaisse d'un logiciel métier sérieux.
Je contribue depuis 2024 à une plateforme de gestion de soins à domicile pour le marché britannique. Vue de l'extérieur, l'application principale ressemble à un calendrier : des intervenants, des bénéficiaires, des visites à planifier. « Un CRUD avec un planning. »
Deux ans plus tard, c'est le produit le plus dense sur lequel j'aie travaillé.
Ce que « planifier une visite » veut vraiment dire
Prenons la fonctionnalité la plus évidente : affecter un intervenant à une visite chez un bénéficiaire, mardi à 9 h.
Voici une partie de ce qu'il faut vérifier :
- L'intervenant est-il disponible ? Pas seulement libre dans le calendrier — pas en congé, pas en arrêt, dans ses horaires contractuels.
- A-t-il les qualifications requises ? Certains actes exigent une habilitation. Certaines habilitations expirent.
- Le temps de trajet depuis la visite précédente est-il réaliste ? Une visite à 9 h et une autre à 9 h 15 à dix kilomètres, c'est un planning qui produit du retard structurel.
- Le bénéficiaire a-t-il des préférences ou des restrictions ? Genre de l'intervenant, langue parlée, refus documenté d'une personne précise.
- Cette affectation crée-t-elle un dépassement d'heures au regard du droit du travail ?
- Génère-t-elle des heures majorées — nuit, week-end, jour férié — qui changent le coût ?
- La visite est-elle couverte par le plan de financement du bénéficiaire ? Sinon, qui paie ?
Sept familles de règles pour un glisser-déposer dans un calendrier. Aucune n'est optionnelle : chacune correspond soit à une obligation légale, soit à un risque financier, soit à la sécurité d'une personne vulnérable.
Le piège du prototype qui marche
Voici comment ces produits dérapent, et c'est presque toujours la même histoire.
Le prototype gère le cas nominal. Il est livré en six semaines, tout le monde est content. Puis les cas réels arrivent, un par un, chacun par un ticket :
- « Et si l'intervenant tombe malade le matin même ? »
- « Et si le bénéficiaire est hospitalisé pendant deux semaines ? »
- « Et si on doit prouver à l'inspection qui est passé quand, il y a quatorze mois ? »
- « Et si deux plannings ont été créés en double par erreur ? »
Chaque cas est traité isolément, par une condition ajoutée là où ça faisait le moins mal. Au bout de dix-huit mois, la fonction d'affectation fait huit cents lignes, personne n'ose y toucher, et chaque correction en casse une autre.
Ce n'est pas un problème de compétence. C'est un problème de modèle : on a modélisé une visite comme une ligne dans un tableau, alors que c'est un engagement contractuel avec un cycle de vie.
Ce qui aide vraiment
Rendre les règles explicites et nommées
Une règle métier enfouie dans un if est une règle perdue. Personne ne peut l'énumérer, la tester isolément, ni expliquer au client pourquoi le système a refusé.
Une règle nommée — IntervenantQualifiePourActe, TempsDeTrajetSuffisant, DansLesHeuresContractuelles — devient un objet du domaine. Elle se teste seule, s'active par client, et surtout elle se restitue : quand une affectation est refusée, on peut dire laquelle des règles a bloqué. C'est la différence entre un logiciel qu'on subit et un logiciel qu'on comprend.
Séparer ce qui est vrai de ce qui est calculé
La confusion la plus coûteuse que j'observe : mélanger les faits et les déductions.
Un fait : « l'intervenant a pointé son arrivée à 9 h 07 ». Immuable, horodaté, jamais recalculé.
Une déduction : « cette visite compte pour 55 minutes de temps facturable en tarif normal ». Résultat d'un calcul, susceptible de changer si le barème change.
Si tu stockes la déduction sans le fait, tu ne peux plus rien recalculer quand une règle évolue — et elle évoluera. Si tu recalcules tout à la volée sans jamais figer, tu ne peux pas expliquer une facture émise il y a huit mois.
La bonne réponse est de garder les deux : les faits comme journal immuable, les déductions comme instantané daté portant la version du barème appliqué.
Accepter que la correction fasse partie du métier
Dans un logiciel de gestion, les données sont fausses. Un intervenant oublie de pointer. Un planificateur saisit le mauvais bénéficiaire. Une visite est annulée après avoir été facturée.
Le réflexe du développeur est d'empêcher l'erreur. C'est illusoire : l'erreur vient du monde physique, pas de l'interface.
Ce qu'il faut, c'est outiller la correction : qui peut corriger quoi, jusqu'à quand, avec quelle trace, et quel effet sur ce qui a déjà été facturé. Une correction n'écrase jamais — elle ajoute une opération inverse et une nouvelle valeur. C'est la comptabilité en partie double appliquée au logiciel, et c'est la seule approche qui survit à un audit.
C'est aussi la fonctionnalité que personne ne demande dans le cahier des charges initial, et que tout le monde réclame au bout de six mois.
Le problème actuel : on forme mal à ça
Voilà ce qui me frappe dans l'état de la profession.
Nous formons des développeurs à la technique : frameworks, algorithmes, patterns, performance. Nous ne les formons quasiment pas à comprendre un métier.
Or dans un logiciel de gestion — et c'est l'immense majorité du logiciel écrit dans le monde — la difficulté n'est presque jamais technique. Elle est dans la compréhension du domaine. Le code qui pose problème n'est pas celui qui est lent : c'est celui qui a modélisé une réalité de travers.
Les compétences qui font la différence sur ces projets :
- Savoir interviewer. Demander « montre-moi comment tu fais aujourd'hui » plutôt que « de quoi as-tu besoin ». Les gens décrivent mal leur propre travail ; ils l'exécutent bien.
- Repérer les cas tordus tôt. La bonne question en réunion de cadrage : « quel a été le cas le plus pénible que tu aies eu à gérer cette année ? » La réponse vaut vingt pages de spécification.
- Refuser de coder ce qu'on n'a pas compris. Un développeur qui implémente une règle qu'il ne sait pas expliquer produira un bug, avec un délai variable.
L'intelligence artificielle accentue ce déséquilibre. Elle écrit du code correct de plus en plus vite. Elle ne sait pas qu'une visite annulée à moins de deux heures reste facturée à 50 % selon le contrat de ce client-là. Ce savoir n'est écrit nulle part — il vit dans la tête d'une personne qu'il faut aller écouter.
Ce qui prend de la valeur, ce n'est plus d'écrire le code. C'est de savoir quel code écrire.
Ce que je vérifie avant d'accepter un projet métier
- Puis-je parler à quelqu'un qui fait le travail ? Pas au sponsor, à l'utilisateur. Si non, je décline.
- Existe-t-il une contrainte réglementaire ? Si oui, elle structure l'architecture et doit être connue avant la première ligne.
- Que se passe-t-il quand c'est faux ? Si la réponse est « on corrige en base », le projet n'est pas prêt.
- Qui arbitre quand deux règles se contredisent ? Il faut un nom, pas un comité.
Ces quatre questions m'ont évité davantage de problèmes que n'importe quel choix technique.
Cette plateforme est décrite sur sa fiche projet, sans détail confidentiel. Si tu portes un logiciel métier dont la complexité t'échappe, écris-moi.