Deux fichiers, une seule formule, deux résultats différents. C’est ce qu’a révélé un ticket de support ouvert par un utilisateur d’une plateforme de calcul de devis pour des travaux d’isolation, qui obtenait un montant différent selon qu’il consultait son devis sur la page de récapitulation ou sur la page d’export PDF. Les deux pages affichaient pourtant, en théorie, le même calcul.
En creusant, la cause est apparue simple à comprendre mais coûteuse à corriger : la formule de calcul du devis — surface, type d’isolant, majoration régionale — existait à deux endroits distincts du projet. Une fois en PHP, dans une fonction utilitaire du plugin métier de WordPress. Une fois en JavaScript, dans un composant du front React chargé d’afficher une estimation en temps réel pendant la saisie du formulaire.
Ce qu’on observe concrètement
Au départ, les deux implémentations étaient rigoureusement identiques : la même majoration régionale de douze pour cent pour certains départements, le même arrondi au centime supérieur. Le front avait sa propre version en JavaScript parce que l’équipe voulait un retour instantané à l’utilisateur pendant la saisie, sans attendre un aller-retour vers l’API à chaque changement de champ, un choix de performance tout à fait défendable en soi.
Le problème n’a pas surgi immédiatement. Il est apparu trois sprints plus tard, quand une évolution commerciale a modifié la majoration régionale pour deux nouveaux départements. Le développeur en charge du ticket a corrigé la fonction PHP, celle utilisée par l’export PDF et par l’API de calcul final. Il n’a pas su, ni même pensé à vérifier, qu’une copie de cette même règle existait côté front, dans un fichier que l’équipe front avait écrit sans jamais documenter son origine.
Pourquoi ça dérive presque toujours
Ce type de duplication ne pose pas de problème le jour où elle est créée : les deux versions sont identiques et le resteront tant que personne n’y touche. La dérive vient de l’asymétrie des équipes qui maintiennent chaque copie. Une règle métier n’est presque jamais gelée : elle évolue au rythme des décisions commerciales, souvent portées par des personnes qui ignorent totalement qu’un même calcul existe en double dans le code.
Le vrai signal d’alerte, en relisant l’historique du projet, était que la fonction JavaScript ne portait aucun commentaire renvoyant vers son équivalent PHP, et inversement. Rien dans le code ne signalait qu’une modification de l’un devait obligatoirement s’accompagner d’une modification de l’autre. Ce silence dans le code a directement permis la divergence.
Quoi faire : un endpoint qui fait autorité
La correction a consisté à supprimer purement et simplement la logique de calcul du composant front, pour la remplacer par un appel à un nouvel endpoint REST dédié, /devis/v1/simuler, qui reçoit les paramètres de saisie et retourne le montant calculé par la seule fonction PHP restante.
register_rest_route( 'devis/v1', '/simuler', array(
'methods' => 'POST',
'callback' => 'dv_simuler_devis',
'permission_callback' => '__return_true',
'args' => array(
'surface' => array( 'type' => 'number', 'required' => true ),
'isolant' => array( 'type' => 'string', 'required' => true ),
'departement' => array( 'type' => 'string', 'required' => true ),
),
) );Le retour instantané pendant la saisie a été conservé, mais avec un léger anti-rebond de trois cents millisecondes sur les appels réseau, un compromis largement acceptable pour l’utilisateur au regard de la garantie retrouvée que le montant affiché soit strictement identique partout dans le parcours.
Ce que cette correction a demandé
- Recenser toutes les autres règles métier potentiellement dupliquées dans le même projet, pas seulement celle signalée par le ticket
- Écrire des tests automatisés côté PHP sur la fonction de calcul, absents jusque-là
- Documenter dans le README du plugin que toute règle de calcul doit vivre exclusivement côté API
En headless, le front n’est pas un endroit pour réimplémenter une règle métier, même simplifiée : c’est un endroit pour l’afficher. Dès qu’un calcul se retrouve à deux endroits, il ne s’agit plus d’une question de style de code, mais d’une dette qui finira par coûter la confiance d’un client.
Ce que cet antipattern ne concerne pas
Les questions de performance liées au nombre d’appels réseau générés par cette centralisation ne sont pas traitées ici : elles ont été jugées secondaires face au risque d’incohérence, et ont fait l’objet d’un travail distinct sur la mise en cache des réponses de simulation les plus fréquentes.
Ce qu’il faut retenir
Une règle métier ne devrait avoir qu’un seul endroit où elle est vraie. Dans une architecture headless, cet endroit doit être l’API, jamais le front, aussi tentant que soit le gain de réactivité perçu par l’utilisateur. La duplication ne se voit pas au moment où elle est écrite ; elle se paie au moment où quelqu’un, ailleurs dans l’organisation, change une règle sans savoir qu’elle vit à deux endroits.
