Pourquoi certaines intégrations coûtent plus cher que les systèmes qu’elles relient.

Le devis porte sur la connexion, la facture porte sur les écarts

L’estimation d’une intégration décrit presque toujours la même chose : lire des données ici, les transformer, les écrire là, avec une authentification et une planification. Cette partie est réelle, bien outillée, et elle se tient généralement dans les délais annoncés.

Ce qui déborde, c’est tout ce qui se trouve entre les deux systèmes : les cas où les données existent des deux côtés mais ne veulent pas dire la même chose, ceux où elles arrivent dans le désordre, et ceux où personne ne sait qui doit trancher. Ces écarts n’apparaissent pas à la conception. Ils apparaissent en production, un par un, et chacun exige une décision d’affaires avant de pouvoir être codé.

Trois écarts qui produisent l’essentiel de la dépense

Le même mot, deux définitions

Un « client actif » désigne, dans l’outil de vente, un compte ayant commandé dans les douze derniers mois. Dans le système comptable, c’est un compte sans solde impayé. Dans la plateforme de commerce, c’est un compte dont l’accès n’a pas été suspendu. Les trois définitions sont légitimes dans leur contexte, et aucune n’est convertible dans les autres sans une règle d’arbitrage que personne n’a écrite.

Ce type d’écart se règle par une décision d’affaires, pas par une transformation technique. Le développement est bloqué tant que l’arbitrage n’a pas eu lieu, et l’arbitrage est bloqué tant que personne n’est désigné pour le rendre.

Les événements n’arrivent pas dans l’ordre

Un système distant renvoie une erreur temporaire, l’appel est relancé, et la même commande est créée deux fois. Une mise à jour d’adresse arrive avant la création du compte qu’elle concerne. Un message est livré deux fois parce que l’accusé de réception s’est perdu.

Ces situations ne sont pas des anomalies rares, ce sont les conditions normales d’un échange entre systèmes indépendants. Les interfaces sérieuses le reconnaissent explicitement : l’interface de programmation de Stripe, par exemple, documente les requêtes idempotentes, qui permettent de rejouer un appel sans créer deux fois la même opération. Décider si les échanges doivent être idempotents, et comment les rejouer, est un choix de conception qui précède le choix de l’outil.

Personne ne possède le flux

Une intégration relie deux équipes autant que deux systèmes. La loi formulée par Melvin Conway en 1968 reste d’une exactitude gênante : les organisations produisent des systèmes dont la structure reproduit celle de leurs communications. Une intégration entre deux services qui se parlent peu sera une intégration mal définie.

Sans propriétaire désigné, chaque incident déclenche la même séquence : chacun vérifie que son côté fonctionne, conclut que le problème vient de l’autre, et le flux reste en panne le temps que la discussion se tienne. Le coût n’est pas dans la correction, il est dans le délai de décision, répété à chaque incident pendant des années.

Une intégration sans propriétaire n’est pas gratuite. Son coût est simplement réparti entre toutes les équipes qui la subissent.

Le raccourci qui coûte le plus cher

Face à ces difficultés, la solution la plus rapide consiste souvent à lire directement dans la base de données de l’autre système. Aucune interface à négocier, aucune limite d’appel, un résultat en quelques jours.

Martin Fowler a décrit depuis longtemps le prix de ce raccourci : une base de données partagée par plusieurs applications devient un contrat implicite entre elles. Plus personne ne peut en modifier la structure sans risquer de casser un consommateur qu’il ne connaît pas. L’intégration est livrée vite, et l’évolution des deux systèmes est ralentie pour toute leur durée de vie.

L’alternative documentée consiste à intercaler une couche de traduction — une couche anticorruption, dans le vocabulaire de la conception pilotée par le domaine — dont le rôle est d’absorber les différences de modèle pour que chaque système conserve le sien. Elle coûte davantage à construire et elle évite précisément le gel décrit plus haut.

Ce qu’il faut décider avant de signer

La plupart de ces coûts se décident avant la première ligne de code, au moment où l’on définit ce qui est échangé et qui en répond. Cinq points suffisent à faire apparaître l’essentiel du travail réel.

Aucun de ces points n’est une question d’outil. Ils se posent de la même manière avec une plateforme d’intégration du marché, une file de messages ou quelques appels programmés — et ils déterminent bien davantage le coût final que le choix de la technologie.

Une intégration coûte cher lorsqu’elle transporte des désaccords non résolus entre deux parties de l’organisation. Une intégration bien préparée ne supprime pas ces désaccords : elle oblige simplement à les trancher avant qu’ils ne deviennent des incidents.