Un jour, votre fournisseur augmentera ses tarifs. Ou ses performances baisseront. Ou un concurrent fera mieux, moins cher.
La question n’est pas de savoir si cela arrivera, mais ce que vous pourrez en faire. Deux issues sont possibles.
Dans la première, vous changez de fournisseur en une intervention bornée, parce que le reste du système ne l’a jamais connu directement.
Dans la seconde, vous le gardez. Pas parce qu’il est bon, mais parce que partir coûterait des mois de chantier, avec une équipe qui redoute chaque modification.
La différence entre les deux s’appelle le découplage.
Une chemise, ça se change en deux minutes
Une chemise se change en deux minutes, tant qu’elle n’est pas cousue à la peau.
Un système informatique qui dépend d’un hébergeur, d’un service de paiement, d’une messagerie, d’un outil de cartographie ou d’un modèle d’IA a le même choix.
Soit le fournisseur est branché à un endroit précis et bien délimité, soit son nom est cousu partout : dans les écrans, dans les calculs, dans les formats de données, dans les habitudes de l’équipe.
Découpler, c’est décider que le reste du système ne connaît pas directement le fournisseur. Il connaît seulement ce qu’il lui demande : « encaisse ce paiement », « envoie ce message », « stocke ce fichier ».
L’interface : un contrat que chaque fournisseur remplit
Une interface est à la conception logicielle ce qu’est un contrat dans la vraie vie.
Sauf qu’ici, le juge est un programme, et il ne plaide pas les circonstances atténuantes : si le contrat n’est pas scrupuleusement respecté, le composant ne peut simplement pas exister.
Ce contrat est fonctionnel : il décrit uniquement ce qu’on doit pouvoir faire, jamais comment, comme un devis décrit ce qui sera livré sans dire comment l’artisan s’y prend.
Pour un paiement, il tient en une ligne : « il faut pouvoir envoyer un paiement et en recevoir un ». Pas un mot sur le fournisseur.
Le fournisseur, lui, ne signe pas directement. Un adaptateur remplit le contrat pour son compte : il couvre chaque clause, intégralement, en s’appuyant sur la façon de faire propre à ce fournisseur.
Une seule clause manquante, et l’adaptateur ne peut pas être branché.
Le reste de votre système est le consommateur du contrat. Il dit « envoie ce paiement » et l’adaptateur fait ce qu’il a à faire. Le consommateur ne sait pas comment cela fonctionne sous le capot, et n’a pas à le savoir.
Changer de fournisseur revient alors à brancher un autre adaptateur, qui remplit le même contrat. Le consommateur n’est pas modifié.
Un exemple : la signature de PDF
Prenons un fournisseur de signature électronique, utilisé pour faire signer des bons de livraison en PDF.
Cet exemple n’est pas théorique : il vient d’une plateforme de bons de livraison dématérialisés, en production depuis 2018.
Le contrat tient en deux clauses : « il faut pouvoir envoyer un document à signer » et « il faut savoir quand il est signé, et par qui ».
Un adaptateur remplit ces deux clauses avec l’interface du fournisseur : ses appels, ses statuts, sa façon de renvoyer le document signé.
Sans cette frontière, l’interface du fournisseur est appelée depuis chaque écran qui touche aux bons de livraison, et depuis l’archivage.
Ses statuts (« en attente », « refusé », « expiré ») sont enregistrés tels quels dans votre base, et ses règles de relance deviennent les vôtres.
Le jour où il augmente ses tarifs, partir revient à reprendre chacun de ces endroits.
Avec la frontière, le système dit « envoie ce document à signer » et reçoit « signé » ou « non signé ».
Changer de fournisseur, c’est écrire un nouvel adaptateur pour les deux mêmes clauses. Les écrans, la base et l’archivage ne bougent pas.
Ce que le couplage vous coûte
Un fournisseur dont vous ne pouvez pas vous séparer est une boîte noire de plus : vous ne maîtrisez ni son évolution, ni son prix, ni sa potentielle disparition.
Il le sait. Il sait que partir vous prendrait des mois.
Alors il augmente ses tarifs, et vous l’annonce « pour mieux vous servir ». Vous n’avez pas de levier de négociation, puisque l’alternative n’existe que sur le papier.
Quand il tombe en panne, c’est votre activité qui s’arrête. Quand il est racheté, vous apprenez la suite par un courriel de changement de conditions.
Les fournisseurs de modèles d’IA en sont l’exemple du moment : on en choisit un, et il arrive qu’un concurrent fasse mieux ou moins cher peu de temps après.
Reste à savoir si votre système peut en profiter ou s’il est marié au premier.
Le même mécanisme, côté éditeurs et intégrateurs, est détaillé dans Ce qui se passe le jour où votre éditeur ou intégrateur n’est plus là.
Le moment où l’on décide compte plus que le principe
Défini pendant l’étude, au moment où l’on dessine l’architecture, et aux bons endroits, le découplage ne coûte pas plus cher à développer que le couplage : le temps de réflexion passe dans l’étude, non pas dans l’écriture du code.
Il y a souvent autant de code, parfois moins : une frontière oblige à encapsuler ce que le fournisseur impose, au lieu de le laisser se répandre dans tout le système.
Elle rend aussi les tests plus simples : on branche un faux fournisseur derrière le contrat, au lieu de dépendre du vrai à chaque exécution.
Les agents IA accélèrent encore cette écriture : produire la pièce qui traduit entre votre système et un fournisseur est la partie la plus mécanique du travail, celle qu’ils font bien.
Mais l’IA ne dessine pas la frontière à votre place. Si personne ne l’a tracée, elle produit du code couplé aussi vite que du code propre.
Reste le scénario que je rencontre le plus : aucune étude sérieuse, et en plein développement, quelqu’un lance « tiens, on va peut-être découpler ça comme ça ».
Sans vue d’ensemble, on découpe là où c’est facile, pas là où le système changera vraiment.
Une seule frontière mal placée, et la facture s’étale en trois temps. Le découpage bancal est payé dès le départ.
Sa correction est d’autant plus lourde qu’il y a de composants à reprendre. Et il y a les dégâts collatéraux : on ne retouche pas un système en profondeur sans casser autre chose.
Découpler en plein développement, c’est chercher la bonne vanne pendant que l’eau coule. On finit par en trouver une. Rarement la bonne.
C’est pour cela que l’architecture se décide avant d’engager le budget de réalisation. C’est la voie « Décider » de mon offre : définir où placer les frontières avant d’écrire la première ligne.
Où découpler, et où ne pas le faire
Découpler partout, c’est du zèle : des couches d’abstraction sur des éléments qui ne changeront jamais complexifient inutilement un projet, et augmentent mécaniquement les coûts pour une valeur ajoutée nulle.
On découple aux endroits où un changement sera probablement utile un jour, par exemple :
- un fournisseur de service (hébergement, paiement, messagerie, IA) dont le prix ou la qualité peut bouger ;
- un éditeur de logiciel dont vous ne maîtrisez pas la suite ;
- un format de données propriétaire, qui vous enferme dans l’outil qui l’a produit ;
- un équipement ou un protocole de terrain, quand le parc est amené à évoluer.
Puis on s’arrête là où il n’y a pas besoin de frontière (vos propres règles métier par exemple : c’est ce que vous gardez, pas ce que vous remplacez).
Savoir quelles dépendances comptent, c’est justement ce que l’étude apporte.
L’excès inverse existe aussi, et il se joue dans le contrat lui-même. Une interface calquée sur le plus petit dénominateur commun de deux fournisseurs prive le système d’une fonction utile à un seul d’entre eux.
Une interface qui laisse passer des notions propres à un fournisseur n’est plus un contrat neutre : son nom revient dans tout le système.
Le contrat décrit ce dont le système a besoin, pas ce que les fournisseurs savent faire.
Ce que je vérifierais si j’arrivais chez vous demain
- Si l’un de vos fournisseurs doublait son prix demain, en combien d’endroits du système son nom apparaît-il ?
- Vos données sont-elles dans un format que vous pouvez emporter ailleurs sans passer par lui ?
- Quelqu’un chez vous sait-il remplacer un fournisseur sans rouvrir le reste ?
- Votre dernier changement de fournisseur a-t-il pu se faire sans arrêter l’activité ?
- Avez-vous déjà renoncé à une meilleure offre parce que changer coûterait trop cher ?
Si la dernière réponse est oui, vous avez déjà un fournisseur qui fixe vos prix à votre place.
Questions fréquentes
Découpler, est-ce tout réécrire ?
Non. Une frontière se pose aux endroits où un fournisseur peut changer, pas dans l’ensemble du système.
Posée après le développement initial, elle peut toutefois toucher de nombreux fichiers : d’où l’intérêt de la penser à l’étude. Sur un système existant, on commence par la dépendance qui pèse le plus, pas par une refonte.
Peut-on découpler un système déjà en production ?
Oui, mais c’est un chantier, et il commence par une étude : où placer les frontières, dans quel ordre, sans casser ce qui fonctionne. L’improviser en cours de route donne en général un découplage qui s’articule mal avec le reste.
Découplage et microservices, est-ce la même chose ?
Non. Les microservices sont une façon de découper un système en morceaux indépendants, pas un synonyme de découplage.
On peut avoir un ensemble très bien découplé dans une seule application, et des microservices si liés entre eux qu’on ne peut en changer aucun.
Les microservices ont leur intérêt dans certains cas. Mais ils ont un prix : chaque service est à déployer, à surveiller et à faire évoluer, et une donnée répartie entre plusieurs services est plus difficile à garder cohérente.
Une équipe qui n’a ni l’outillage ni le temps pour cela en subit le coût sans en tirer le bénéfice.
Faut-il tout découpler ?
Non, et il faut être pragmatique. Il faut seulement découpler ce qui peut raisonnablement changer. Le reste ne mérite pas la complexité d’une frontière.
À retenir
- Découpler, c’est faire en sorte que le reste du système ne connaisse pas directement son fournisseur, seulement ce qu’il lui demande.
- Un fournisseur dont on ne peut pas se séparer fixe ses prix et son rythme à votre place.
- Défini à l’étude, et aux bons endroits, un découplage ne coûte pas plus cher à développer que le couplage. Improvisé en plein développement, il est presque toujours mal placé faute de vue d’ensemble et vous coûte cher.
- On découple aux endroits où le changement est plausible, pas partout.
C’PRAG commence par un cadrage technique : la cartographie des dépendances réelles de votre système.
L’approche pragmatique
- Cartographie de vos dépendances.
- Identification des frontières qui comptent.
- Recommandations priorisées.
- Architecture définie, si vous le souhaitez, avant que vous engagiez le budget de réalisation.
Sans casser ce qui fonctionne, et sans vous enfermer chez un autre fournisseur.
Réservez un échange préalable de 15 minutes pour en parler : la première cartographie révèle presque toujours des dépendances que personne n’avait identifiées.