Six lots fonctionnels, chacun testé et relu, ont produit dix défauts sérieux une fois réunis. Ils avaient été conçus comme indépendants alors qu’ils modifiaient les mêmes devis, sites d’intervention et contacts, appliquaient les mêmes règles métier et réécrivaient certains fichiers communs.
Le logiciel planifie des interventions, envoie des devis à signer et prévient les clients par SMS. Le parallélisme avait raccourci le développement de chaque lot tandis que le travail nécessaire pour obtenir un produit cohérent restait intact.
Deux lots corrects, un parcours incohérent
Un lot ajoutait l’acceptation d’un devis en ligne : le système vérifiait le devis, confirmait la commande et produisait la facture. Un autre permettait au back-office de modifier le site d’intervention ou de supprimer la demande associée. Chaque comportement était cohérent et couvert par ses tests.
Ensemble, ils ouvraient une brèche entre la vérification et la confirmation. Le back-office pouvait modifier le site d’intervention pendant que le client signait. Le client validait alors la version courante du devis, tandis que le prestataire de signature conservait un contrat décrivant l’ancienne version.
Aucun test isolé ne couvrait cette séquence. Le défaut se trouvait dans leur jointure, autour d’un state partagé qui pouvait changer avant l’acte irréversible.
Les tickets masquaient un système partagé
- Une règle métier dupliquée. Trois chemins devaient conserver le destinataire d’un devis, avec trois définitions : une empreinte complète du contact, son identifiant ou aucune vérification.
- Un state relu trop tôt. Deux requêtes pouvaient charger le même brouillon et générer deux PDF, sans moyen fiable de déterminer ensuite lequel représentait l’offre acceptée.
- Un artefact partagé. Deux branches réécrivaient le schéma de la base. Le merge avait supprimé une table nécessaire aux rendez-vous, malgré un code correct dans chaque branche.
Produire plus vite déplace le goulot
Lorsque chaque lot peut interagir avec tous les autres, le nombre maximal de paires à examiner suit la formule n × (n - 1) / 2 :
| Lots parallèles | Calcul | Paires possibles |
|---|---|---|
| 6 | 6 × 5 / 2 |
15 |
| 10 | 10 × 9 / 2 |
45 |
Ces 15 ou 45 paires ne correspondent pas à autant de conflits. Elles forment un plafond ; le coût réel dépend de la densité du graphe de dépendances et du coût de chaque jointure.
L’IA permet à un développeur de lancer plusieurs chantiers à faible coût. La génération, les tests locaux et la review se parallélisent bien. Réconcilier deux interprétations d’une règle métier reste un travail séquentiel qui exige de comprendre le produit entier.
Avant de lancer les lots en parallèle
- Cartographier les lectures et écritures. Pour chaque lot, noter les objets lus ou modifiés, les invariants et les artefacts partagés.
- Classer les dépendances. Si un lot écrit ce qu’un autre lit ou écrit, ou s’ils partagent un invariant ou un artefact, leur intégration doit être planifiée ensemble.
- Empiler les dépendances de code. Si une PR utilise le code ou le schéma de la précédente, la faire partir de cette branche pour qu’elle n’affiche que son diff. Fusionner la stack du bas vers le haut et restack ses descendantes après chaque changement. Une dépendance métier seule exige une coordination d’intégration et un test commun, pas forcément une stack.
- Fermer les races. Lier la signature à une version immuable du devis et du site, puis comparer cette version dans la même transaction que la confirmation. Si elle diffère, invalider la signature et régénérer le contrat.
- Tester après chaque merge. Régénérer les artefacts partagés, puis rejouer les parcours métier touchés. Une suite verte sur chaque PR ne couvre pas leurs jointures.
- Planifier l’intégration. Nommer la personne qui intègre, fixer la cadence et réserver le temps nécessaire. La date annoncée doit inclure ce travail.