Le module de paie : le calcul est la partie facile

Tout le monde connaît la règle du hors-jeu. Elle tient en deux phrases.

Et pourtant on y consacre des minutes d'arbitrage vidéo, des lignes tracées au pixel, des débats sans fin. Parce que connaître la règle et l'appliquer à vingt-deux joueurs en mouvement sont deux métiers différents.

La paie, c'est exactement ça. La formule est triviale. L'appliquer au réel ne l'est pas.

Je contribue depuis 2024 à une plateforme de gestion de soins à domicile pour le marché britannique. Le module qui calcule ce que l'agence facture à ses clients et ce qu'elle verse à ses intervenants est, de loin, celui qui m'a le plus appris.

La version naïve

rémunération = heures_travaillées × taux_horaire

Voilà. Dix minutes de développement, tests compris.

Maintenant, les questions qui arrivent dans les six mois :

• L'intervenant a pointé à 9 h 07 pour une visite prévue à 9 h. On paie à partir de quand ?
• Il a oublié de pointer sa sortie. On paie quoi ?
• La visite était prévue, le bénéficiaire était absent. On paie ? Le client est facturé ?
• La visite chevauche minuit un samedi. Combien d'heures en tarif normal, combien en majoré ?
• L'intervenant a fait 46 heures cette semaine. Les six heures au-delà sont majorées de combien, et à partir de quel seuil exactement ?
• Le trajet entre deux visites : temps de travail ou pas ?
• Le barème a changé au 1^er avril. On recalcule le mois de mars ?

Aucune de ces questions n'est technique. Toutes changent le montant que quelqu'un touche à la fin du mois.

La distinction qui sauve tout : faits et déductions

C'est la leçon que je retiens le plus de ce produit, et elle dépasse largement la paie.

Un fait : « l'intervenant a pointé son arrivée à 9 h 07 le 14 mars ». Horodaté, immuable, jamais recalculé. C'est arrivé.

Une déduction : « cette visite compte pour 53 minutes de temps facturable au tarif de nuit ». C'est le résultat d'un calcul, avec une version de barème, à une date donnée.

La faute classique est de ne stocker que la déduction. Le montant est en base, le fait qui l'a produit ne l'est plus. Le jour où une règle change — et elle changera — tu ne peux plus rien recalculer. Le jour où un client conteste une facture de huit mois, tu ne peux plus rien expliquer.

La faute inverse existe aussi : tout recalculer à la volée, ne jamais figer. Alors une facture émise en janvier change de montant quand tu déploies en juin. Personne ne peut travailler comme ça.

La bonne réponse garde les deux : les faits comme un journal qu'on n'écrase jamais, les déductions comme un instantané daté qui porte la version du barème appliqué. Une facture, c'est un calcul figé à un moment, avec la trace de la règle qui l'a produite.

La correction fait partie du métier

Le réflexe du développeur, face à une donnée fausse, est d'empêcher l'erreur. Validation plus stricte, champs obligatoires, contrôles à la saisie.

C'est illusoire. L'erreur ne vient pas de l'interface, elle vient du monde physique. L'intervenant a oublié son téléphone. Le planificateur a saisi le mauvais bénéficiaire. La visite a été annulée par téléphone et personne ne l'a enregistrée.

Ce qu'il faut, ce n'est pas empêcher : c'est outiller la correction.

Qui a le droit de corriger quoi. Jusqu'à quand. Avec quelle trace. Et surtout : quel effet sur ce qui a déjà été facturé et payé.

La règle que j'applique désormais : 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 met dans le cahier des charges initial, et que tout le monde réclame au bout de six mois.

Les arrondis, qui valent plus cher qu'on ne croit

Un détail qui paraît mesquin et ne l'est pas.

53 minutes à 12,40 £ de l'heure font 10,953333… £. Tu arrondis à quoi ? À la visite, ou à la fin du mois sur le total ?

Les deux méthodes donnent des résultats différents. Sur une visite, l'écart est d'un centime. Sur quatre cents visites mensuelles pour cent intervenants, l'écart devient une ligne dans une réunion.

Trois règles que j'applique sans exception :

• Jamais de flottant pour de l'argent. On stocke des entiers dans la plus petite unité — des centimes, des francs. Le flottant introduit des erreurs qui ne se voient qu'au millième et se voient très bien à la fin du trimestre.
• Le moment de l'arrondi est une décision métier, pas un détail d'implémentation. On la documente.
• Le sens de l'arrondi aussi. En faveur de qui, quand ça tombe pile au milieu ?

Personne ne demande ça. Tout le monde le remarque quand c'est faux.

Ce qu'une règle nommée change

Une règle métier enfouie dans un if est une règle perdue. Personne ne peut l'énumérer, la tester seule, ni expliquer au client pourquoi le système a calculé ça.

Une règle nommée — MajorationNuit, SeuilHeuresHebdomadaires, TempsDeTrajetFacturable — devient un objet du domaine. Elle se teste isolément. Elle s'active par client. Et surtout elle se restitue : à côté du montant, on peut afficher quelles règles ont été appliquées et dans quel ordre.

C'est la différence entre une facture qu'on subit et une facture qu'on comprend. Et commercialement, c'est ce qui fait qu'une agence reste : elle peut répondre à ses propres clients sans t'appeler.

Le problème de fond

Il y a un déséquilibre que ce produit m'a rendu évident.

On forme des développeurs à la technique — frameworks, algorithmes, performance. On ne les forme quasiment pas à interroger 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.

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, et il tourne très vite.

L'automatisation accentue ça. Un assistant écrit une fonction de calcul de paie correcte en quelques secondes. Il ne sait pas que chez ce client-là, une visite annulée à moins de deux heures reste facturée à 50 %. Ce savoir n'est écrit nulle part — il vit dans la tête d'une personne qu'il faut aller écouter. J'ai développé ce point ailleurs.

Les quatre questions avant de coder un calcul d'argent

1. Quel est le fait, et quelle est la déduction ? Si tu ne sais pas les séparer, ne commence pas.
2. Que se passe-t-il quand la règle change ? Recalcul rétroactif, ou pas ? Qui décide ?
3. Comment on corrige une erreur déjà facturée ? S'il n'y a pas de réponse, le produit n'est pas prêt.
4. Qui peut expliquer ce montant à un client mécontent ? Si la réponse est « le développeur », il manque une fonctionnalité.

Ces quatre questions m'ont évité plus d'ennuis que n'importe quel choix d'architecture.

Cette plateforme est décrite sur sa fiche projet, sans détail confidentiel. Si tu construis un produit qui calcule de l'argent — facturation, paie, commissions — on peut en parler.