---
title: Six lots en parallèle, et la facture arrive à l'intégration
description: Six lots corrects séparément ont créé dix défauts à l'intégration. Le
  coût du parallélisme dépend des règles, états et artefacts qu'ils partagent.
url: https://sxnlabs.com/opinion/2026/08/05/parallelisme-la-facture-arrive-a-l-integration/
lang: fr
date: '2026-08-05T09:00:00+02:00'
tags:
- Méthode
- Projet
- Intégration
- IA
---

# Six lots en parallèle, et la facture arrive à l'intégration

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.

<figure class="schema">
  <picture>
    <source media="(max-width: 640px)" srcset="/images/posts/parallelisme-integration/convergence-mobile.fr.svg?v=20260827-layering" width="375" height="564" />
    <img width="940" height="494" src="/images/posts/parallelisme-integration/convergence.fr.svg?v=20260827-layering" alt="Six lots validés séparément convergent deux par deux vers les mêmes objets, règles métier et artefacts, puis vers une intégration qui révèle dix défauts sérieux." />
  </picture>
  <figcaption>Le découpage séparait les tickets tout en laissant communes les surfaces qu'ils modifiaient.</figcaption>
</figure>

## 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

<figure class="schema">
  <picture>
    <source media="(max-width: 640px)" srcset="/images/posts/parallelisme-integration/stack-devis-signature-read-write-mobile.fr.svg" width="375" height="810" />
    <img width="940" height="544" src="/images/posts/parallelisme-integration/stack-devis-signature-read-write.fr.svg" alt="Le back-office modifie le site d'intervention que le parcours de signature lit. Cette dépendance impose une coordination et un test commun ; les PR sont empilées seulement si la seconde dépend du code de la première." />
  </picture>
  <figcaption>Le chevauchement lecture/écriture impose une coordination, pas automatiquement une stack. La seconde PR part de la première seulement si elle dépend de son code ou de son schéma.</figcaption>
</figure>

1. **Cartographier les lectures et écritures.** Pour chaque lot, noter les objets lus ou modifiés, les invariants et les artefacts partagés.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.