La crise du « Glue Code » : pourquoi l'orchestration distribuée de workflows est difficile

SchemaBridge Team · 2025-12-01 · Distributed Systems, Architecture, DevOps

Cessez de gaspiller du temps d'ingénierie en plomberie d'API. Découvrez pourquoi l'orchestration distribuée de workflows est la clé pour faire évoluer des systèmes fragmentés en 2026.

Le goulet d'étranglement architectural : un tueur silencieux de productivité

En tant que développeur senior ou architecte, vous avez déjà vécu ce cycle : vous commencez par une intégration « simple » — synchroniser une commande Shopify avec un ERP historique. Vous écrivez un script de 50 lignes, l'enveloppez dans une Lambda ou un cron job, et vous le livrez. Il fonctionne le premier jour. Il fonctionne le dixième. Puis le monde change. L'API Shopify ajoute un rate limit. L'ERP historique subit une contention de verrous en base de données à 2 h du matin. Un transporteur tiers modifie la structure de sa réponse JSON.

Sans que vous vous en rendiez compte, votre « script rapide » est devenu une brique d'infrastructure critique. Mais il n'a pas été construit comme de l'infrastructure ; il a été construit comme un script. Il n'a pas de gestion d'erreurs digne de ce nom, ne comprend pas la notion d'état et n'a aucune résilience intégrée. Quand il échoue, il échoue en silence, ou pire, il échoue partiellement — laissant vos données dans un état corrompu qui demande des jours de travail manuel pour être réparé.

Trois mois plus tard, ce script de 50 lignes a muté en un monstre de 5 000 lignes. Il gère désormais les retries (mal, avec des boucles infinies), écrit ses logs à trois endroits différents (dont un est plein) et contient des blocs try-except imbriqués qui masquent les vraies erreurs. Vous avez 20 scripts de ce genre qui tournent dans votre infrastructure. Ils sont le « Glue Code » de votre organisation. Ce n'est pas de l'ingénierie ; c'est de la plomberie réactive.

C'est la crise du Glue Code. C'est le tueur silencieux de la vélocité d'ingénierie. Vous ne construisez plus de fonctionnalités qui font avancer votre activité ; vous construisez et entretenez des « tuyaux » fragiles qui fuient des données, se bouchent sous la charge et éclatent à 3 h du matin, déclenchant des alertes qui réveillent vos meilleurs ingénieurs. Dans un monde de microservices fragmentés et d'API SaaS innombrables, sans stratégie d'orchestration durable, vous construisez en somme une maison sur un ciment à prise rapide. Elle paraît solide pendant une semaine, mais les fissures sont inévitables.

Les racines historiques de la crise : de CGI-BIN au cloud

Pour comprendre pourquoi nous en sommes là, il faut revenir sur l'histoire de l'intégration logicielle. Dans les années 1990, nous avions les scripts CGI et Perl. C'étaient de petites commandes sans état qui transformaient une requête en réponse. C'était le « Glue Code » originel. Ils étaient formidables pour leur époque, mais n'ont jamais été conçus pour gérer les parcours en plusieurs étapes, sur plusieurs jours, d'une entreprise numérique moderne. C'étaient des outils « fire and forget » dans un monde qui n'était pas encore toujours connecté ni interconnecté à l'échelle mondiale.

Dans les années 2000, nous sommes passés aux ESB (Enterprise Service Buses) — des middlewares massifs et lourds comme Tibco ou BizTalk. Ils étaient puissants, mais incroyablement complexes et coûteux. Ils cherchaient à tout centraliser, ce qui a créé un goulet d'étranglement autour des « architectes du bus ». Chaque changement exigeait une réunion de comité. Le bus est devenu précisément ce qu'il devait résoudre : un point de défaillance unique et une source massive de friction organisationnelle.

Dans les années 2010, nous avons rejeté l'ESB au profit des microservices. Nous sommes passés aux API REST et aux scripts légers (Python, Go, Node.js). Nous pensions gagner en liberté. En réalité, nous avons déplacé la complexité du « bus » vers « l'espace entre les services ». Nous avons remplacé un middleware unique et lourd par des milliers de petits scripts fragiles disséminés dans l'environnement. Nous vivons désormais dans un monde où la complexité est en O(N^2) par rapport au nombre de nos services. Nous avons échangé un goulet d'étranglement centralisé contre un chaos décentralisé.

La psychologie du script : pourquoi nous choisissons encore des voies fragiles

Pourquoi continuons-nous à écrire des scripts ? Même les ingénieurs seniors, qui connaissent les pièges des systèmes distribués, choisissent souvent le « script rapide » plutôt que « l'orchestrateur durable ». La raison est psychologique.

1. L'illusion du « quick win »

Quand une partie prenante métier demande une nouvelle intégration, elle la veut « pour hier ». Un script donne une impression de rapidité. Vous l'écrivez en une heure. Vous vous sentez productif. Vous « cochez la case ». Mais c'est une fausse productivité. Vous contractez un prêt à taux élevé sur votre capacité future. Les heures gagnées aujourd'hui, vous les rendez au centuple le mois prochain à déboguer un échec partiel en production. Le script est une drogue pour les managers d'ingénierie qui privilégient les indicateurs à court terme sur la stabilité à long terme.

2. L'effet Dunning-Kruger des systèmes distribués

Beaucoup de développeurs pensent que « les retries, c'est facile ». Ils croient qu'envelopper un appel d'API dans une boucle while avec une temporisation suffit. Ils n'ont pas encore connu la tempête de retries, l'identité orpheline ou la corruption d'état qui surviennent dans un véritable environnement de production. Ils se trouvent au « pic des attentes exagérées » quant à leur propre capacité à gérer les pannes. Ce n'est qu'à la première panne majeure à 3 h du matin qu'ils comprennent que l'état distribué est un problème qui exige des solutions au niveau de l'infrastructure.

3. L'absence d'une meilleure unité de travail

Jusqu'à récemment, il nous manquait une unité de travail standard pour l'orchestration. Nous avions des « fonctions » et des « services », mais pas de « parcours ». SchemaBridge introduit le Durable Workflow comme cette unité de travail. Il permet d'exprimer un parcours en plusieurs étapes comme une entité unique dont l'état est persisté, de sorte qu'un crash ou un redémarrage d'un worker reprend l'étape en cours au lieu de perdre le parcours.

Anatomie d'un échec : pourquoi les « scripts » ne passent pas à l'échelle

Un script qui fonctionne pour 10 utilisateurs échoue à 10 000 pour trois raisons principales, inhérentes à la nature des systèmes distribués. Nous ne pouvons pas résoudre ces problèmes avec du « meilleur code » seul ; nous devons les résoudre avec de l'infrastructure.

1. Le problème du succès partiel : l'état « à moitié cuit »

Dans un système distribué, le succès n'est pas binaire. Supposons que votre script effectue trois étapes : 1) Débiter le client via Stripe. 2) Mettre à jour la base de données d'inventaire interne. 3) Envoyer un e-mail de confirmation via SendGrid. Que se passe-t-il si le processus plante après l'étape 1 ?

Le client est débité, mais votre inventaire est toujours marqué « En stock », et l'utilisateur n'a reçu aucun reçu. Pour résoudre cela avec du code brut, vous devez écrire à la main des patterns Saga complexes — en somme, un mini-orchestrateur pour chaque script. Vous devez vérifier si le débit a eu lieu, vérifier l'état de l'inventaire et gérer les rollbacks. Ce code passe-partout finit par dominer votre temps de développement, et vous vous trompez encore parfois, parce que l'état distribué est difficile.

2. Le fossé de l'idempotence : le danger des retries

La connectivité est capricieuse. Un script intercepte un timeout d'une API et réessaie. Mais si l'API avait en réalité réussi, et que seule la réponse avait expiré ? Sans idempotence, votre retry entraîne un double débit ou une double expédition. La plupart des développeurs de « Glue Code » l'ignorent jusqu'au jour où un client est débité de 5 000 $ au lieu de 500 $.

Ajouter des clés d'idempotence à chaque appel d'API sur des dizaines de services est un fardeau logistique que peu d'équipes assument de façon cohérente. Avec 100 intégrations, vous avez 100 endroits où oublier une clé. Un moteur d'orchestration peut vous en décharger en partie, mais soyez précis sur la partie concernée. SchemaBridge déduplique les déclencheurs entrants (par un hash du contenu du payload, ou par une clé que vous fournissez), de sorte qu'un fournisseur qui renvoie le même webhook ne démarre pas deux fois le même parcours. Les effets de bord sortants, en revanche, s'exécutent at-least-once : une étape peut être réexécutée après un crash. Pour une destination non idempotente, transmettez dans l'appel lui-même une clé d'idempotence dérivée d'un champ métier stable (un identifiant de commande, un payment intent).

Les huit illusions : les fondations de l'échec

Pour vraiment comprendre pourquoi le Glue Code échoue, il faut revenir aux huit illusions de l'informatique distribuée (Fallacies of Distributed Computing), formulées pour la première fois par Peter Deutsch et d'autres chez Sun Microsystems. Ce sont les hypothèses erronées que fait tout développeur lorsqu'il commence à écrire du code réseau. Ce sont les « faux paradis » de l'ingénierie :

1. Le réseau est fiable : Il ne l'est pas. Les paquets se perdent, les routeurs redémarrent et les câbles sont coupés. Dans un environnement cloud, à grande échelle, attendez-vous à une panne réseau intermittente chaque jour.

2. La latence est nulle : Elle ne l'est pas. Même les réseaux de fibre mondiaux les plus rapides introduisent des millisecondes de délai qui s'accumulent sur des milliers d'appels. Ce délai est irrégulier et imprévisible, et provoque des race conditions qui disparaissent dès que vous essayez de les déboguer en local.

3. La bande passante est infinie : Elle ne l'est pas. Les gros payloads engorgent vos tuyaux et déclenchent des timeouts. Les fournisseurs cloud imposent en outre des quotas de bande passante stricts qui brideront votre « Glue Code » sans prévenir.

4. Le réseau est sûr : Il ne l'est pas. Les attaques man-in-the-middle, l'empoisonnement DNS et les tokens divulgués sont des menaces permanentes. Votre script de « Glue Code » est une cible de choix pour le vol d'identifiants s'il n'est pas correctement isolé.

5. La topologie ne change pas : Elle change. Les load balancers se déplacent, les nœuds meurent et les adresses IP sont recyclées. « L'IP codée en dur » de votre script est une bombe à retardement.

6. Il n'y a qu'un administrateur : Ce n'est pas le cas. Vous êtes à la merci d'AWS, de Cloudflare et de chaque fournisseur SaaS de votre stack. Quand ils modifient leur API, votre script est la première victime.

7. Le coût de transport est nul : Il ne l'est pas. Sérialiser et désérialiser du JSON à grande échelle a un coût réel en CPU et en mémoire. Un script peut passer une part étonnante de son temps à simplement parser et re-parser des payloads dans json.loads().

8. Le réseau est homogène : Il ne l'est pas. Votre stack mélange Linux, Windows, JVM, Node et des services SOAP historiques. Attendre un comportement figé dans un tel paysage est une illusion.

Plongée technique : event sourcing et scalabilité de la persistance

L'une des parties les plus difficiles de la construction d'un moteur d'orchestration durable est la gestion de la persistance de l'état. Lorsqu'un grand nombre de workflows s'exécutent simultanément et que chacun effectue de nombreuses étapes, la charge d'écriture sur votre couche de persistance augmente rapidement.

Le goulet d'étranglement de la base de données

Un schéma naïf — une ligne workflow_history large et mutable, réécrite avec l'état complet à chaque étape — finira par céder sous cette charge, car la contention sur les index et les verrous des lignes chaudes devient le principal goulet d'étranglement. SchemaBridge scinde le problème en deux sur PostgreSQL : un petit enregistrement d'état courant qui change, et un historique qui ne fait que croître.

1. Des lignes de statut petites et protégées : L'état courant de chaque exécution et de chaque étape réside dans des lignes de statut compactes, mises à jour par des écritures conditionnelles de type compare-and-set (une étape ne passe de DISPATCHED à EXECUTING que si personne d'autre ne l'a revendiquée avant). Les gros payloads sont entièrement tenus hors de ces lignes et déportés dans un stockage objet SeaweedFS (compatible S3), et Valkey Streams assure la livraison du travail entre les étapes.

2. Des traces d'exécution en ajout seul : Chaque étape ajoute aussi un enregistrement de trace immuable, ce qui vous donne une piste étape par étape de l'exécution. La table des traces est partitionnée par mois, de sorte que les anciennes partitions sont supprimées à moindre coût lorsqu'elles dépassent la durée de rétention, au lieu d'être effacées ligne par ligne.

3. Reprise après crash sans réhydratation : Comme l'état courant est durable, un worker n'a jamais à le reconstruire en mémoire. Si un worker meurt au milieu d'une étape, la revendication de l'étape expire et un autre worker la reprend et la réexécute. C'est une exécution at-least-once, et c'est exactement pour cela que le conseil ci-dessus sur l'idempotence sortante est important.

Le fossé de gouvernance : à qui appartient la plomberie ?

Au-delà des défis techniques se trouve un défi culturel : le fossé de gouvernance. Dans une architecture microservices traditionnelle, la responsabilité est cloisonnée. L'équipe du « Product Service » possède la base de données produits. L'équipe du « Shipping Service » possède l'intégration FedEx.

Mais à qui appartient le pont entre les deux ?

Généralement, à personne. Le script de « Glue Code » est écrit par un développeur qui a besoin d'un correctif rapide, puis il est abandonné. Quand il casse, l'équipe Product accuse l'équipe Shipping, et l'équipe Shipping accuse le fournisseur de l'API. Il n'existe aucune « source de vérité » centrale décrivant comment les processus métier sont réellement connectés.

SchemaBridge résout ce problème en faisant de l'intégration un actif global.

La métaphore biologique : le logiciel comme système nerveux

Nous allons vers un monde où le logiciel n'est plus une collection d'outils statiques, mais un système nerveux vivant. Dans un système nerveux biologique, un signal voyage du doigt (le capteur) au cerveau (la logique) puis revient au muscle (l'action). Si une partie du chemin est bloquée, le système s'adapte. Il a des réflexes. Il a une mémoire.

L'orchestration durable est le système nerveux de l'entreprise. Elle permet à vos services fragmentés de se comporter comme un organisme unique et cohérent.

1. Les réflexes : Les retries automatiques avec backoff absorbent les petites « douleurs » (un 5xx transitoire, une réponse de rate limit, une connexion interrompue lors d'un appel HTTP) sans solliciter le cerveau (le développeur).

2. La mémoire : L'état d'exécution est persisté, de sorte qu'après un redémarrage — même de tout le cluster — les étapes en cours sont reprises et réexécutées au lieu d'être oubliées. Comme cette réexécution est at-least-once, les effets de bord doivent toujours être idempotents côté destination.

3. La conscience : L'observabilité visuelle (voir Le fossé de l'observabilité) vous permet de voir chaque exécution en direct : quelle étape s'exécute, laquelle a échoué, et le payload qui est entré et sorti.

Scénario illustratif : l'effondrement silencieux du rapprochement

Pour mesurer la gravité de la crise, prenons une fintech qui rapproche chaque jour les transactions entre son grand livre interne et les API de plusieurs banques partenaires à l'aide d'un grand ensemble de scripts Python.

La panne

Imaginez qu'un vendredi, une banque partenaire change le schéma d'authentification de son API de rapprochement. Le script Python ne plante pas ; il est simplement rejeté, intercepte l'exception et marque « silencieusement » le rapprochement du jour comme « Pending ». Comme il n'existe pas de tableau de bord visuel, la panne passe inaperçue pendant des jours.

Quand quelqu'un finit par regarder, un écart important et croissant s'est accumulé entre le grand livre et les banques. Les auditeurs sont sollicités, la direction est prévenue, et l'équipe d'ingénierie doit passer des jours à reconstruire à la main la chronologie du rapprochement. Le script fonctionnait parfaitement sur le « happy path », mais il n'avait aucune capacité d'« auto-réparation » et aucune « vérité visuelle ».

L'alternative SchemaBridge

Imaginez maintenant la même logique de rapprochement exécutée sur SchemaBridge. Lorsqu'un changement d'authentification similaire survient, le vertex Gateway (l'appel HTTP sortant vers la banque) échoue, et l'exécution passe au rouge dans le moniteur, avec la réponse rejetée attachée à l'étape en échec. SchemaBridge n'alerte personne de lui-même, mais l'équipe peut rendre ce cas bien visible : avec le clientErrorMode du gateway réglé sur complete, un appel rejeté (4xx) devient un résultat invalid_input sur lequel elle peut router, directement vers une étape de notification Slack. Dans les deux cas, la panne est visible le jour même plutôt que des jours plus tard. L'équipe corrige l'identifiant, clique sur Retry (Réessayer) sur l'étape en échec, et le rapprochement reprend là où il s'était arrêté au lieu d'être reconstruit à la main.

Ressources recommandées pour une orchestration sans erreur

Si vous voulez maîtriser l'art de l'exécution durable, nous vous recommandons la liste de lectures suivante :

Conclusion : le nouveau mandat de l'architecte

La crise du Glue Code est le symptôme d'une transition. Nous passons d'un monde de « silos et de scripts » à un monde d'« écosystèmes connectés ». Dans ce nouveau monde, les connexions entre vos services sont aussi importantes que les services eux-mêmes.

Votre mandat d'architecte ne se limite plus à construire des services fiables ; il s'agit de construire des connexions fiables. Le Glue Code est l'antithèse de la fiabilité. C'est un correctif temporaire qui devient inévitablement un fardeau permanent. Il est temps d'arrêter de construire des tuyaux fragiles et de commencer à construire un système nerveux numérique.

En adoptant un moteur d'orchestration durable comme SchemaBridge, vous reprenez en main l'avenir de votre ingénierie. Vous construisez des systèmes qui connaissent leur état, résistent aux pannes et sont visibles par toute l'organisation. C'est ainsi que vous retrouvez votre vélocité et construisez des systèmes qui durent.

Cet article fait partie de notre série Building the Bridge. Voir aussi : Concevoir pour la vélocité : plaidoyer pour l'ingestion d'événements sans schéma — l'approche « late binding » de l'ingestion d'événements.

Explorer