La demande paraît anodine. Une équipe a besoin de la date de résiliation d’un contrat pour alimenter un nouveau parcours. L’information existe déjà, quelque part, dans le système de gestion. Monter un chantier d’intégration pour si peu semble disproportionné : on ouvre un accès en lecture sur la base, on écrit une requête, l’affaire est réglée en trois jours. Tout le monde a bien travaillé, et vite.

Dix-huit mois plus tard, l’équipe qui gère ce système veut restructurer une table et découvre qu’elle ne peut plus. Elle ignore précisément qui lit sa base, et surtout ce que ces lecteurs supposent — que ce champ n’est jamais vide, que cette valeur signifie « résilié » et non « en cours de résiliation », que la mise à jour se fait la nuit. Chaque modification devient une négociation avec des interlocuteurs qu’il faut d’abord retrouver. Le système n’est pas mal conçu. Il est simplement devenu impossible à faire évoluer, parce qu’une dizaine de raccourcis de ce genre ont transformé son modèle interne en interface publique, sans que personne ne l’ait jamais décidé.

Le réflexe, à ce stade, est de chercher une solution dans l’outillage : il nous faudrait une vraie plateforme d’intégration, un catalogue d’API, un bus d’événements. Ces briques sont utiles et souvent nécessaires. Mais elles ne traitent pas la cause. C’est la thèse de cet article : le désordre d’intégration n’est presque jamais un problème de transport. C’est un problème de responsabilité et de signification. Une interface sans propriétaire identifié, sans définition explicite de ce qu’elle transporte, sans règle d’évolution ni date de fin, restera ingérable quelle que soit la technologie qui l’achemine. Le livrable d’architecture, en matière d’intégration, n’est pas la topologie : c’est le contrat. Et ce contrat est un actif — il se conçoit, s’entretient, se retire, et il détermine ce que l’organisation pourra changer l’année suivante.

Le tuyau change, le problème reste

L’intégration a connu plusieurs générations technologiques, et chacune s’est présentée comme la fin du désordre.

Les échanges de fichiers et les connexions point à point ont d’abord relié ce qui devait l’être, au cas par cas. Puis les plateformes d’intégration centralisées ont promis de remplacer cet enchevêtrement par un point de passage unique, capable de router, transformer et superviser. Les architectures orientées services ont ensuite déplacé l’attention vers le contrat d’appel et la réutilisation. Les API web et leurs passerelles de gestion ont rendu l’exposition simple, mesurable et sécurisée. Les plateformes d’intégration en mode service et les bus d’événements ont enfin apporté l’échelle, le découplage et la diffusion en continu.

Chacune de ces générations a produit des gains réels — sur le transport, le format, la sécurité, l’observabilité. Aucune n’a réglé le problème de fond, et le constat se répète à chaque migration : on retrouve, sur la nouvelle plateforme, les mêmes interfaces qu’avant, ré-hébergées. Les points d’échange ont changé de forme ; ni leur nombre, ni leur opacité, ni leur fragilité n’ont diminué.

La raison est simple. Ces outils traitent excellemment trois questions — comment acheminer, sous quel format, avec quelle supervision — et n’en traitent aucune des trois qui font mal : qui possède cette interface, que signifie exactement ce qu’elle transporte, et comment elle a le droit d’évoluer. Ce sont des questions de conception et de responsabilité. Aucun produit ne les tranche à la place de l’organisation.

Un mode d’échec mérite d’être nommé au passage, parce qu’il survit à toutes les générations : l’absorption de la logique métier par la couche d’intégration. Il commence par une petite règle de commodité placée dans une transformation — un enrichissement, un aiguillage conditionnel, une valeur par défaut. Elle est là parce que c’est l’endroit le plus rapide pour la mettre. Quelques années plus tard, la couche d’intégration porte des décisions métier que personne ne sait plus énoncer, et l’équipe qui l’exploite se retrouve responsable d’un comportement dont elle n’a le mandat sur rien. Une règle de conduite en découle : la couche d’intégration achemine, traduit, protège. Elle ne décide pas.

L’interface de fait

Avant de gouverner ses interfaces, une organisation doit admettre lesquelles existent — et la liste est toujours plus longue que le catalogue.

L’accès direct en base de données du chapitre précédent en est une. L’export nocturne déposé sur un serveur de fichiers en est une. La table d’échange partagée entre deux applications en est une. Le robot qui rejoue une interface graphique parce qu’aucun service n’était disponible en est une. La copie « temporaire » d’un référentiel, mise en place pour un projet et jamais retirée, en est une.

Le point n’est pas de condamner ces montages, dont beaucoup étaient la seule réponse raisonnable au moment où ils ont été faits. Il est de constater qu’une interface non déclarée reste une interface : elle crée exactement le même couplage, la même dépendance et le même verrou sur les évolutions futures qu’un service publié — mais sans propriétaire, sans description, sans engagement de service et sans possibilité de la retirer proprement. Elle a tous les inconvénients d’un contrat et aucune de ses garanties.

L’intégration a par ailleurs une propriété désagréable : elle révèle les défauts de gouvernance de la donnée sans les corriger. Le jour où deux systèmes doivent échanger sur le même client, il faut bien trancher lequel des quatre identifiants fait foi et ce que « client actif » veut dire de part et d’autre. Ces questions ne sont pas des questions d’intégration ; ce sont des questions de propriété et de définition, que le projet d’intégration découvre parce qu’il est le premier à ne pas pouvoir les contourner. Les traiter dans le mappage, en codant en dur une correspondance dans une transformation, revient à enterrer le problème à l’endroit où personne ne le cherchera.

Ce que contient réellement un contrat d’interface

Un contrat d’interface n’est pas un fichier de description technique. La description est le support ; le contrat est ce qui est promis. Il couvre huit points, dont trois seulement figurent habituellement dans les spécifications.

Un propriétaire. Une personne ou une équipe qui décide de ce que l’interface expose, arbitre les demandes d’évolution et répond quand elle dysfonctionne. Sans cela, tout le reste est décoratif. La propriété de l’interface suit celle de la capacité métier qu’elle expose — pas celle de la plateforme qui l’héberge.

Une sémantique. La définition métier de chaque élément transporté, dans les termes du glossaire de l’organisation, et non par son nom technique. Ce que recouvre exactement « date d’effet », si le montant est hors taxes ou toutes taxes comprises, dans quelle devise, quel fuseau horaire, si une valeur absente signifie « inconnue » ou « sans objet ». La majorité des incidents d’intégration durables ne viennent pas d’un format invalide, qui est détecté immédiatement, mais d’un malentendu de signification, qui ne l’est jamais.

Une forme. Le schéma, le typage, les champs obligatoires et optionnels, les cardinalités, les valeurs admises. C’est la partie que les outils savent vérifier automatiquement, et c’est pour cela qu’elle est la mieux tenue.

Des garanties de livraison. Le message peut-il arriver deux fois ? Se perdre ? Arriver dans le désordre ? Ces trois questions ont des réponses différentes selon le mécanisme, et elles engagent le consommateur autant que le producteur. Une livraison « au moins une fois » — le cas le plus courant en asynchrone — impose une conséquence directe : le traitement doit être idempotent, c’est-à-dire produire le même résultat s’il est rejoué. Cela suppose une clé stable dans le contrat, décidée avec l’interface et non ajoutée après le premier double traitement.

Une fraîcheur. À quel point la donnée reçue peut-elle être ancienne ? Un consommateur qui prend une décision métier sur une information dont il ignore l’âge prend un risque qu’il n’a pas instruit. La fraîcheur attendue est une clause du contrat, au même titre que le format.

Un comportement en erreur. Quels codes signalent quoi, lesquels autorisent un réessai et lesquels l’interdisent, à quelle cadence, dans quelles limites de débit. Une interface qui ne dit pas si une erreur est rejouable laisse chaque consommateur inventer sa propre politique — et les réessais non coordonnés sont un mécanisme d’amplification bien connu des incidents.

Un volume et un niveau de service. Les débits attendus, les pics, la latence visée, les quotas par consommateur. Cela protège autant le producteur, qui sait ce qu’il doit tenir, que le consommateur, qui sait ce sur quoi il peut compter.

Un cycle de vie. Les règles d’évolution compatible, la politique de version, la durée de support, le préavis de retrait. C’est le point le plus systématiquement omis, et celui qui décide de tout le reste sur la durée. Nous y revenons plus bas.

Un contrat correctement instruit répond à une question précise : que puis-je changer sans prévenir personne, et que dois-je négocier ? Tant que cette frontière n’est pas écrite, elle est fixée par défaut au périmètre le plus large possible — c’est-à-dire que plus rien ne peut changer.

Trois questions de forme, et comment les trancher

Le choix du style d’intégration précède le choix de l’outil, et il se ramène à trois arbitrages.

Synchrone ou asynchrone ? La bonne question n’est pas la performance, mais le couplage temporel : ai-je besoin de la réponse pour poursuivre l’action en cours ? Appeler un service en synchrone, c’est hériter de sa disponibilité et de sa latence, ainsi que de celles de ses propres dépendances, souvent invisibles depuis l’appelant. Chaque dépendance synchrone ajoutée sur un parcours en réduit mécaniquement la disponibilité atteignable. Le synchrone se justifie quand la réponse conditionne la suite immédiate — une autorisation, une vérification bloquante, une consultation à la demande — et qu’un refus propre est un comportement acceptable. Dès que l’objectif est de propager une information, l’asynchrone est presque toujours le bon choix : il découple les rythmes, absorbe les indisponibilités et laisse le consommateur traiter à sa cadence.

Commande ou événement ? Une commande est une intention adressée à un destinataire connu : fais ceci. Un événement est un fait déjà survenu, publié sans savoir qui l’écoutera : ceci s’est produit. La distinction n’est pas cosmétique, car elle désigne qui décide. Le piège le plus fréquent est l’événement qui est une commande déguisée : un message nommé « client à facturer » n’est pas un fait, c’est un ordre — le producteur a décidé à la place du consommateur, et le couplage qu’on croyait avoir supprimé est intact.

Le même arbitrage se rejoue à l’échelle du processus. En orchestration, un composant connaît la séquence complète et pilote les étapes : le processus est lisible en un endroit, testable, traçable — au prix d’un point central qui sait beaucoup de choses. En chorégraphie, chaque composant réagit aux événements qu’il observe : le couplage est faible, mais il n’existe plus aucun endroit où lire le processus de bout en bout, ce qui se paie le jour où il faut expliquer à un auditeur pourquoi un dossier s’est arrêté à mi-parcours. Un partage raisonnable consiste à orchestrer les processus métier de bout en bout qui portent un enjeu de traçabilité ou de conformité, et à chorégraphier la diffusion d’information entre domaines.

Direct ou médié ? Le point à point n’est pas une faute en soi ; c’est sa généralisation silencieuse qui coûte. Deux composants d’un même domaine, sous la même responsabilité, gagnent rarement à passer par une médiation. En revanche, dès qu’un échange franchit une frontière de responsabilité ou qu’un même flux intéresse plusieurs consommateurs, la médiation se justifie : elle donne un point d’observation, permet d’ajouter un consommateur sans toucher au producteur, et évite que chaque nouveau besoin ne crée un lien de plus. Le critère n’est donc pas technologique : il est organisationnel.

Ne pas exposer son modèle interne

C’est la décision qui produit le plus d’effets à long terme, et elle tient en une phrase : le contrat n’est pas le reflet de la base de données.

Exposer son modèle interne — par un accès direct, par un export brut de tables, par une interface qui recopie fidèlement des structures internes — revient à donner à ses consommateurs un droit de veto sur ses propres évolutions. Le producteur perd la liberté de restructurer ce qu’il possède, non pas parce que c’est techniquement difficile, mais parce que la conséquence est devenue imprévisible. Le système se fige de l’extérieur.

Un contrat bien conçu est au contraire une projection délibérée : il expose ce que le domaine veut promettre à l’extérieur, dans un vocabulaire stable, et garde pour lui la façon dont il s’organise en interne. La traduction entre les deux — entre le modèle interne et le modèle publié — a un coût réel : c’est un mappage à maintenir. Ce coût achète exactement une chose, et elle vaut cher : le droit de changer l’intérieur sans négocier avec l’extérieur.

Une règle complète ce principe. Cette traduction doit rester une traduction. Si le mappage se met à décider — à choisir un statut, à appliquer un seuil, à arbitrer entre deux sources — alors une règle métier a quitté son propriétaire pour s’installer dans un endroit que personne ne considère comme une application. C’est le mode d’échec décrit plus haut, et il commence toujours par une exception qui semblait raisonnable.

Faire évoluer sans casser

Une interface utile change. La question n’est pas de l’éviter mais de rendre le changement possible sans coordination générale.

La règle par défaut est la compatibilité ascendante : on ajoute des éléments optionnels, on ne retire rien, on ne rend rien obligatoire qui ne l’était pas, on ne restreint pas un ensemble de valeurs admises. Un consommateur qui ignore ce qu’il ne connaît pas peut alors continuer à fonctionner sans rien faire — encore faut-il que cette tolérance soit elle-même une clause du contrat, et non une propriété accidentelle de son implémentation.

Le changement le plus dangereux n’est cependant pas celui qui casse le schéma : celui-là est détecté immédiatement, et c’est une bonne nouvelle. Le plus dangereux est celui qui conserve le nom et change la signification — un statut dont on élargit le sens, un montant qui devient net après avoir été brut, une date qui passe d’une convention à une autre. Rien ne se casse. Les traitements continuent, et produisent des résultats faux pendant des mois. C’est la raison pour laquelle la sémantique doit figurer dans le contrat : ce qui n’est pas écrit ne peut pas être versionné.

Quand la rupture est inévitable, elle se traite par une version explicite — en assumant que faire coexister deux versions coûte, ce qui implique de dater la fin de la première dès la publication de la seconde. Une interface sans date de retrait ne meurt jamais : elle accumule des consommateurs jusqu’à devenir intouchable, exactement comme l’accès en base du début de cet article.

Reste l’obstacle pratique : on ne retire pas ce dont on ignore l’usage. Deux dispositifs y répondent. Le registre des consommateurs — savoir qui appelle quoi, par déclaration à l’abonnement ou par observation du trafic — transforme une question insoluble en liste de correspondants. Les tests de contrat côté consommateur, où chaque consommateur exprime sous forme exécutable ce qu’il attend réellement de l’interface, permettent au producteur de vérifier avant publication ce qu’il casse. C’est le seul moyen connu de faire évoluer une interface partagée avec confiance plutôt qu’avec précaution.

Ce que l’architecture doit tenir

Rien de tout cela n’exige d’examiner chaque interface en comité — ce serait reproduire le goulot d’étranglement que la gouvernance d’architecture cherche justement à éviter. Le rôle de l’architecture se concentre sur quatre choses.

Fixer les conventions par défaut, une fois, pour que chaque équipe n’ait pas à les réinventer : styles d’échange autorisés et cas d’usage de chacun, format des erreurs, conventions de temps et de devise, règles d’identification, pagination, versionnement. Une convention respectée par défaut vaut mieux qu’un standard arbitré au cas par cas.

Tenir un catalogue des interfaces qui porte le propriétaire, pas seulement la description technique. Un catalogue sans nom de propriétaire en face de chaque ligne est un inventaire, pas un instrument de gouvernance.

Réserver la revue aux interfaces qui le justifient : celles qui franchissent une frontière de domaine, celles qui sortent de l’organisation, celles qui transportent des données sensibles ou réglementées. Le reste relève de la responsabilité des équipes, dans le cadre des conventions.

Automatiser l’assurance plutôt que la contrôler : validation de schéma à la construction, détection des ruptures de compatibilité, exécution des tests de contrat des consommateurs, alerte sur les interfaces sans propriétaire ou sans consommateur actif.

Les indicateurs utiles suivent la même logique. Le nombre d’API publiées ne dit rien de la santé du paysage d’intégration. Ce qui la dit : combien d’interfaces n’ont pas de propriétaire identifié, combien fonctionnent sans qu’on sache qui les consomme, combien reposent sur un accès direct au modèle interne d’un autre système, et combien tournent encore sur une version dont le support a expiré.

L’intégration est le lieu où l’architecture devient vraie

Une organisation ne se caractérise pas par la liste de ses applications. Elle se caractérise par ce qu’elle peut changer, et à quelle vitesse — et cette capacité se lit presque entièrement dans ses interfaces. Remplacer une application dont les contrats sont explicites, les consommateurs connus et les évolutions versionnées est un projet : périmètre borné, effort estimable. Remplacer une application dont personne ne sait qui lit quoi est une aventure, dont le coût réel n’apparaît qu’après l’engagement.

C’est en cela que le contrat d’interface est un actif, et non une formalité de documentation. Il n’est pas la trace d’une décision d’architecture : il est la décision. Il fixe ce que chaque domaine promet, ce qu’il garde libre, et ce que les autres ont le droit de supposer. Le reste — le bus, la passerelle, le format, le protocole — n’est que la manière dont ce contrat est acheminé. C’est utile, cela se remplace, et cela n’a jamais été le sujet.