Piège 9 - L'intégration

Le pont qui a raté de 54 centimètres

Laufenburg est une ville coupée en deux par le Rhin : une moitié allemande, une moitié suisse. En 2003, les deux côtés ont commencé à construire un nouveau pont pour les relier. Chaque pays a construit depuis sa propre rive, avec ses propres ingénieurs, vers un point de rencontre au milieu.

Tout le monde connaissait le piège à l’avance. L’Allemagne mesure les altitudes à partir de la mer du Nord, la Suisse à partir de la Méditerranée, et les deux références diffèrent de 27 centimètres. Les ingénieurs ont donc prévu une correction. Quelque part dans les calculs, elle a été appliquée dans le mauvais sens.

Quelques jours avant Noël, lors d’un contrôle de routine, l’équipe de chantier a remarqué que les deux moitiés se rejoindraient avec 54 centimètres d’écart. Deux tronçons étaient déjà coulés dans le béton.

L’histoire finit bien. L’erreur a été détectée à temps, corrigée, et le pont a ouvert comme prévu en décembre 2004. Mais elle n’est apparue qu’une fois le béton coulé, pas le jour où les deux équipes se sont mises d’accord sur ce que signifiait « zéro ». Les deux équipes avaient fait un excellent travail. Chaque moitié était juste. Le pont était faux.

Chaque moitié était juste

Les grands programmes sont construits comme ce pont. Le travail est réparti entre équipes, fournisseurs et systèmes, chacun avec son propre plan, son propre backlog et sa propre définition de « terminé ». Chaque équipe construit soigneusement sa moitié. Chacune est au vert.

Ce qu’aucune équipe ne possède, c’est le milieu : les interfaces, les données qui circulent entre les systèmes, les environnements partagés, les hypothèses que tout le monde croyait évidentes. Alors le milieu est construit en dernier, lors de la phase d’intégration vers la fin du plan, quand tout est censé simplement se connecter.

C’est là que les programmes découvrent que deux systèmes entendent des choses différentes par « client », que les données de test ne ressemblent en rien aux données de production, que la migration prend trois jours au lieu d’un week-end, et que le test de performance que personne n’a lancé échoue à un dixième de la charge attendue. Chacun de ces problèmes était là dès la première semaine. Ils étaient simplement invisibles jusqu’à ce que les deux moitiés se rencontrent.

C’est cela, le piège de l’intégration : construire les parties en parallèle et découvrir le tout à la fin, quand chaque surprise coûte le plus cher.

Les dix visages du piège

En 25 ans, je l’ai vu prendre dix formes, en trois familles : quand on connecte, ce qu’on suppose, et ce qu’on découvre trop tard. La plupart des programmes qui trébuchent à la mise en production en présentent au moins quatre.

Quand on connecte

Chaque équipe sur sa rive. Le programme est découpé par équipe, fournisseur ou système, et chaque partie a son propre plan. L’intégration entre elles appartient au plan de tout le monde, c’est-à-dire de personne.
Pas de squelette ambulant. Après des mois de programme, il n’existe toujours aucun flux qui fonctionne de bout en bout, de l’écran de l’utilisateur jusqu’au dernier système back-end et retour. Chaque composant existe ; le parcours, non.
L’intégration big bang. Toutes les parties sont connectées en même temps, dans une seule « phase d’intégration » vers la fin. Quand quelque chose casse, personne ne peut dire laquelle des vingt nouvelles connexions en est la cause.

Ce qu’on suppose

Des contrats seulement sur le papier. Les interfaces sont décrites dans un document de spécification, signé il y a des mois. Personne ne les teste automatiquement, donc chaque côté implémente sa propre lecture de la même page.
Même mot, sens différent. Pour un système, un « client » est une personne ; pour un autre, un contrat ; pour un troisième, un foyer. « Date » signifie date de réservation ici et date de valeur là. Chaque équipe a raison dans son propre contexte.
Des environnements qui ne correspondent pas. L’intégration est testée dans un environnement avec des versions différentes, une configuration différente et un dixième des données. Ça marche là-bas. La production est un autre pays.

Ce qu’on découvre trop tard

La migration en un week-end. Déplacer des années de données est prévu comme une bascule unique, répétée une fois, si tant est qu’elle le soit. Elle prend trois fois plus de temps que la fenêtre ne le permet.
Des données sales, découvertes tard. Des doublons, des champs manquants, des valeurs que personne ne sait expliquer. Les vraies données ne rencontrent le nouveau système qu’à la première répétition complète, et chaque règle écrite sur des données de test propres casse.
La performance après la recette. Les tests fonctionnels passent, le métier valide, puis le test de charge est lancé pour la première fois. Les décisions d’architecture qu’il aurait changées ont été prises il y a un an.
La sécurité à la fin. Le test d’intrusion est planifié deux semaines avant la mise en production. Ce qu’il trouve ne peut être corrigé qu’en retardant le lancement ou en acceptant le risque.

Là où vit la vérité

Le piège de l’intégration est difficile à voir parce que chaque signal local a l’air sain. Les tests de chaque équipe passent. Chaque composant est démontré. Le risque ne vit pas à l’intérieur des parties ; il vit entre elles, et le coût d’un écart grandit à chaque mois où il reste caché.

Deux moitiés, deux unités. En 1999, la NASA a perdu Mars Climate Orbiter après un voyage de neuf mois. Le logiciel d’une équipe produisait des données de poussée en livres-force secondes ; l’équipe de navigation attendait des newtons-secondes. Les deux équipes étaient compétentes, les deux logiciels fonctionnaient, et la sonde est arrivée trop bas et a été perdue. L’interface était la seule chose que personne n’avait testée de bout en bout.

Sept serveurs sur huit. En août 2012, Knight Capital a déployé un nouveau code de trading sur ses serveurs de routage d’ordres, mais l’un des huit ne l’a jamais reçu. Un ancien indicateur, réutilisé pour la nouvelle fonctionnalité, a réveillé un programme dormant sur ce serveur. En environ 45 minutes, l’entreprise a accumulé plus de 400 millions de dollars de pertes, et a eu besoin d’un sauvetage dans les jours suivants. Chaque serveur fonctionnait exactement comme il était configuré. Ils n’étaient simplement pas configurés de la même façon.

Le schéma derrière ces deux histoires est le même que celui que les programmes vivent tous les jours. Les problèmes d’intégration ne sont pas plus difficiles que les autres ; ils sont plus tardifs. Un décalage trouvé en deuxième semaine coûte une conversation. Trouvé en phase d’intégration, il coûte une replanification. Trouvé en production, il coûte la crédibilité du programme.

Signaux précoces

On peut mesurer l’écart au milieu bien avant que les moitiés ne se rencontrent :

Après des mois de programme, aucun parcours utilisateur ne fonctionne de bout en bout.
Le plan présente l’intégration comme une phase vers la fin, pas comme un travail continu.
Personne ne peut nommer le responsable de l’intégration entre deux équipes données.
Les interfaces sont décrites dans des documents, mais pas testées automatiquement.
Deux équipes utilisent le même terme métier et en donnent des définitions différentes.
L’environnement de test contient une fraction des données de production, ou des données beaucoup trop propres.
La migration des données n’a jamais été répétée avec des volumes réels.
Le test de charge et le test de sécurité sont planifiés après la recette fonctionnelle.
Chaque équipe est au vert, et personne ne peut dire si le programme fonctionne.

Construire le pont depuis le milieu

La réponse n’est pas d’arrêter de découper le travail. Les grands programmes ont besoin d’équipes en parallèle. C’est de se mettre d’accord sur « zéro » d’abord, connecter tôt, et continuer à connecter : faire de l’intégration le battement de cœur quotidien du programme, pas son examen final.

Construire d’abord un squelette ambulant. Avant qu’aucun composant ne soit terminé, connectez le flux de bout en bout le plus fin possible à travers tous les systèmes, dans un environnement proche de la production. Puis épaississez-le. Dès la première semaine, le pont existe ; il n’est simplement pas encore large.
Nommer un propriétaire pour le milieu. Chaque interface entre deux équipes a un propriétaire nommé, et le flux de bout en bout a une personne responsable. L’intégration est un livrable, pas une phase.
Transformer les contrats en tests. Décrivez chaque interface sous une forme lisible par machine et testez les deux côtés contre elle à chaque changement, avec des tests de contrat. Un contrat cassé fait échouer un build, pas une mise en production.
Se mettre d’accord sur les mots. Écrivez un court glossaire partagé pour les termes métier qui traversent les frontières des systèmes, avec un responsable pour chaque définition. Quand deux systèmes veulent dire des choses différentes, rendez la traduction explicite, à un seul endroit.
Garder les environnements honnêtes. Construisez chaque environnement à partir du même code et de la même configuration, et vérifiez que ce qui est déployé est bien ce que vous croyez. Les différences entre environnements doivent être délibérées et listées.
Répéter la migration, encore et encore. Migrez de vraies données tôt, avec des volumes réels, et réconciliez les résultats automatiquement. Le jour de la mise en production, la bascule devrait être la dixième répétition, pas la première représentation.
Rencontrer les vraies données tôt. Profilez les données de production dès le premier mois. Leurs doublons, leurs trous et leurs bizarreries sont des exigences, pas des surprises.
Tester la performance et la sécurité dès le départ. Intégrez les contrôles de charge et de sécurité dans le pipeline, sur le squelette ambulant, pour que leurs conclusions arrivent tant que l’architecture peut encore changer.
Intégrer en continu, livrer souvent. Des intégrations petites et fréquentes signifient que lorsque quelque chose casse, seuls quelques changements peuvent en être la cause. L’intégration big bang signifie que tout peut l’être.

Ce qu’il faut éviter

Une « phase d’intégration » à la fin du plan.
Des interfaces qui n’existent que sous forme de documents signés.
Supposer que deux équipes entendent la même chose par le même mot.
Tester avec des données propres et peu volumineuses, et les qualifier de représentatives.
Un unique week-end de migration, jamais répété.
Des tests de charge et de sécurité planifiés après la recette.
Rapporter le statut de chaque équipe sans vue de bout en bout.

Le tournant de l’IA

L’IA permet à chaque équipe de construire plus vite sa moitié du pont. Cela ressemble à une bonne nouvelle, et à l’intérieur de chaque équipe, c’en est une. Mais des moitiés plus rapides ne se rejoignent pas plus précisément ; elles se rejoignent simplement plus tôt, avec plus de béton coulé de chaque côté. Quand chaque équipe peut générer un service, un schéma ou une API en un après-midi, le nombre d’interfaces croît plus vite que la capacité de quiconque à les vérifier. Et un agent IA qui travaille dans le dépôt d’une équipe voit le monde de cette équipe : il implémentera volontiers « client » comme cette base de code le définit, sans savoir que le système d’à côté veut dire autre chose.

Utilisée sur le milieu plutôt que sur les moitiés, l’IA change la donne dans l’autre sens. Elle peut lire deux spécifications d’interface et lister leurs désaccords. Elle peut générer des tests de contrat, des données synthétiques avec des bizarreries réalistes, et des scripts de réconciliation pour chaque répétition de migration. Elle peut comparer les environnements et signaler les dérives de configuration avant qu’elles n’atteignent la production. Le meilleur usage de l’IA dans un grand programme pourrait bien être le moins glamour : vérifier patiemment que les deux moitiés vont se rejoindre.

Se mettre d’accord sur zéro

Le pont de Laufenburg est debout aujourd’hui, et relie voitures et piétons entre deux villes qui n’en ont toujours fait qu’une. Les habitants sourient encore des 54 centimètres. Les ingénieurs ont pu corriger parce que quelqu’un a vérifié le milieu avant que le tablier ne soit fermé.

Les meilleurs programmes sur lesquels j’ai travaillé n’étaient pas ceux qui avaient les meilleures équipes de chaque côté. C’étaient ceux où quelqu’un parcourait le milieu chaque semaine : en exécutant le flux de bout en bout, en comparant les définitions, en répétant la migration jusqu’à ce qu’elle devienne ennuyeuse. Leurs mises en production étaient calmes. C’est le plus beau compliment qu’un programme puisse recevoir.

Alors, à votre prochaine revue de programme, posez une question en douceur : pouvez-vous me montrer une vraie transaction, de bout en bout, à travers tous les systèmes, aujourd’hui ? Si la réponse est « pas encore, c’est prévu pour la phase d’intégration », vous savez déjà où se cachent vos 54 centimètres.

Avez-vous déjà vu deux moitiés d’un programme se rejoindre au milieu, ou se rater ? J’aimerais sincèrement entendre votre histoire.

Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans.