La spirale de mort du système — et comment les agents IA l'ont brisée

Résumé :Après huit ans à construire des systèmes, j'ai découvert un schéma prévisible : chaque système finit par devenir inutilisable à cause de l'écart entre les flux de travail conçus et la complexité du monde réel. Cet écart se creuse à cause de la créativité humaine, des contraintes de temps, des outils qui se chevauchent et de la dette de documentation. J'ai cessé d'essayer de construire des systèmes parfaits. Au lieu de cela, j'ai construit un trio d'agents IA qui gèrent la saisie de données, la détection d'anomalies et le patching des systèmes — créant une infrastructure auto-réparatrice qui élimine l'écart au lieu de le gérer.

Le schéma dont personne ne parle

Depuis 2016, Mercury a construit et expérimenté de nombreux systèmes.

Nous avons construit notre propre ERP et CRM. Défini nos flux de travail. Adopté des outils prêts à l'emploi et les avons assemblés avec Zapier, n8n et des intégrations personnalisées. Nous étions fiers de notre pile. Cela semblait sophistiqué. On avait l'impression de faire ce qu'une entreprise moderne devrait faire.

Mais au cours des six derniers mois, j'ai regardé en arrière sur les huit dernières années et j'ai vu quelque chose que je ne voulais pas voir :

Une spirale de la mort. Et c'est partout.

Voici comment cela fonctionne. Vous construisez un système. Vous définissez le flux de travail. Les cas d'utilisation sont limités à ce flux de travail par conception. Puis l'entreprise se développe. De nouvelles situations émergent. Les cas particuliers se multiplient. Les gens commencent à utiliser le système de manière "créative" pour laquelle il n'était jamais destiné. Les données se retrouvent dans les mauvais champs. Les rapports deviennent peu fiables. Quelqu'un crée un tableau Excel fantôme pour "réparer" le problème. Maintenant, vous avez deux sources de vérité. Puis trois.

L'écart entre le système et la réalité continue de se creuser.

Finalement, le système devient inutilisable. Pas parce que la technologie a échoué. Mais parce que le écart entre ce que le système suppose et ce que l'entreprise fait réellement est devenu trop grand pour être comblé.

Chez Mercury, cela s'est produit au ralenti. Nos données CRM ne vivaient pas dans notre CRM. Elles vivaient dans notre plateforme de messagerie, notre cœur CRM, nos journaux d'appels PBX et nos fils de courriels. Même client. Cinq représentations différentes. Aucune d'entre elles n'était entièrement cohérente. Lorsque nous avons réalisé un rapport trimestriel, la réconciliation de ces sources a pris des jours. Parfois, nous avons trouvé des écarts qui avaient existé pendant des mois — des données saisies "créativement" par des employés qui trouvaient le flux de travail officiel trop rigide pour des situations réelles avec des clients.

J'ai observé ce schéma dans des entreprises clientes. Je l'ai observé dans des entreprises avec des départements informatiques de cent personnes. Les mécanismes varient. Le schéma est universel.

D'où vient l'écart

L'écart a quatre sources. Aucune d'entre elles n'est technique.

Créativité humaine.Votre personnel n'est pas composé de robots. Lorsque le système ne correspond pas à la situation, ils improvisent. Ils saisissent des données dans des champs de contournement. Ils utilisent la section "notes" pour des données structurées. Ils créent des processus parallèles en dehors du système car c'est plus rapide que d'attendre que l'informatique corrige quelque chose.

Temps.Même lorsque vous identifiez le problème, le correctif prend du temps. Il y a toujours une priorité plus élevée. Le problème reste dans le backlog pendant des mois. Pendant ce temps, le contournement devient la nouvelle norme.

Prise de décision.Que devez-vous corriger ? Pourquoi ? Dans quel ordre ? La plupart des organisations ne peuvent pas répondre clairement à cela. Le problème persiste car personne n'a l'autorité et le contexte pour décider ce que signifie même "correct".

Documentation.Au moment où quelqu'un documente comment le contournement fonctionne, trois autres contournements ont émergé. La documentation est toujours en retard par rapport à la réalité. Parfois, elle est activement trompeuse.

Et puis il y a le facteur aggravant : chevauchement.

Vos données CRM ne vivent pas dans votre CRM. Elles vivent dans votre plateforme de messagerie, le cœur de votre CRM, votre système PBX, vos fils de discussion par e-mail et les notes personnelles du représentant commercial. Même client. Cinq représentations différentes. Aucune d'entre elles n'est entièrement cohérente. Lorsque vous générez un rapport, laquelle est vraie ?

Ce n'est pas un bug. C'est l'état naturel de toute organisation qui existe depuis plus de deux ans.

La réponse traditionnelle (et pourquoi elle échoue)

La réponse traditionnelle consiste à construire un meilleur système. Plus flexible. Plus configurable. Plus "à l'épreuve du futur".

J'ai essayé cela. Ça ne fonctionne pas.

Plus vous rendez un système flexible, plus il devient complexe. Plus il devient complexe, plus l'écart entre la capacité conçue et l'utilisation réelle s'élargit. La flexibilité n'élimine pas l'écart. Elle le déplace simplement à un niveau d'abstraction plus élevé.

Les fournisseurs de logiciels d'entreprise vendent de la "flexibilité" depuis des décennies. Chaque mise en œuvre commence par "nous allons le configurer selon vos flux de travail" et se termine par "vos flux de travail doivent changer pour correspondre au système." L'écart gagne toujours.

Ce que j'ai construit à la place

Il y a environ un mois, j'ai arrêté d'essayer de construire le système parfait.

Au lieu de cela, j'ai conçu pour l'écart lui-même.

J'ai construit un trio d'agents IA. Pas des chatbots. Pas des assistants. Une couche opérationnelle qui se situe entre les humains et les systèmes et gère le désordre qui s'accumule toujours.

Agent Un : Le Point d'Entrée.

Le personnel interagit avec cet agent pour la saisie de données. Langage naturel. Pas de formulaires. Pas de champs. L'agent pose des questions de clarification, structure les données et les écrit au bon endroit dans le bon format. Si la situation ne correspond pas aux catégories existantes, il ne force pas un carré dans un trou rond. Il le signale.

Agent Deux : L'Analyste.

Lorsque l'Agent Un détecte une anomalie — quelque chose qui ne correspond pas au schéma actuel, un nouveau modèle, un contournement en cours — il escalade vers l'Agent Deux. Cet agent analyse l'anomalie, identifie la cause profonde et génère un rapport : ce qui se passe, pourquoi cela se passe, quels changements système élimineraient l'écart et quels sont les compromis.

Le rapport arrive sur mon bureau. Je le passe en revue. J'approuve ou modifie la recommandation.

Agent Trois : L'Implémenteur.

Une fois approuvé, l'Agent Trois exécute. Il corrige le système. Met à jour le schéma. Modifie l'intégration. Rédige la documentation. Et il le fait non pas comme un projet ponctuel, mais comme un processus continu.

L'écart ne s'accumule plus. Il se ferme en temps réel.

Les résultats, même au cours de ce premier mois, sont frappants. Notre cycle moyen de comblement d'écart — le temps entre l'identification d'un décalage dans le flux de travail du système et sa correction — était auparavant mesuré en trimestres. Début 2026, nous l'avions compressé à environ deux semaines grâce à une meilleure discipline de processus. Avec le trio d'agents, le cycle actuel est de moins de quatre heures pour les changements non structurels, et le même jour pour des ajustements au niveau du schéma qui nécessitent mon approbation.

Les feuilles de calcul fantômes disparaissent. Pas parce que nous l'avons imposé. Parce que le système reflète maintenant la réalité avec suffisamment de précision pour que les gens n'aient plus besoin de solutions de contournement.

C'est le même principe qui sous-tend notre méthodologie GEO. Notre cadre d'audit GEO unifié — celui qui a noté mtsoln.com à 82 (Méthode A 91, Méthode B 76) lors de la ré-audit du 27 août — est construit sur la fermeture continue des écarts, et non sur une optimisation ponctuelle. L'écart entre la façon dont les systèmes d'IA représentent votre marque et la façon dont vous opérez réellement ne se ferme pas dans les projets. Il se ferme par une observation et une adaptation persistantes. Nous appliquons cela aux sites des clients. Maintenant, nous l'appliquons à notre propre infrastructure.

Ce que cela signifie réellement

Ce n'est pas de l'automatisation. L'automatisation suppose que le processus est connu et répétable. C'est quelque chose de différent. C'est une infrastructure adaptative.

Le système ne tente pas de prédire chaque cas d'utilisation. Il n'en a pas besoin. Il observe ce qui se passe réellement, identifie les écarts et évolue pour s'y adapter. Le "système parfait" devient inutile car le système n'est jamais terminé — il devient continuellement plus précis par rapport à la réalité.

Cette approche est désormais la base de deux choses chez Mercury :

Nos services GEO.L'optimisation du moteur génératif ne concerne pas les meilleures pratiques statiques. Il s'agit de s'adapter continuellement à la façon dont les systèmes d'IA représentent votre marque. Le même principe s'applique : observer, analyser, adapter, mettre en œuvre.

Notre cœur ERP/CRM.Le système n'impose pas de flux de travail rigides. Il apprend des flux de travail. L'écart entre le processus conçu et le processus réel devient le signal qui stimule l'amélioration, et non le bruit qui dégrade la fiabilité.

L'objection à laquelle vous pensez

"Cela semble instable." "Que se passe-t-il si les agents apportent de mauvaises modifications ?" "Qu'en est-il de la gouvernance ?"

Ce sont des préoccupations valables. Voici comment je les aborde :

L'approbation humaine est obligatoire pour les changements structurels.L'Agent Deux propose. J'approuve. L'Agent Trois met en œuvre. La boucle est rapide — souvent le même jour — mais la décision humaine reste le verrou. Au cours de ce premier mois, j'ai rejeté ou modifié environ 15 % des propositions. Généralement parce que l'agent a identifié un véritable écart mais a proposé une solution qui créerait un chevauchement ailleurs. L'analyste n'a pas le contexte commercial complet. C'est pourquoi l'humain reste dans la boucle.

Les changements sont réversibles.Chaque correctif est documenté et versionné. Si quelque chose casse, nous revenons en arrière. La documentation est écrite par l'agent qui a effectué le changement, donc elle est en fait précise — contrairement à la documentation humaine qui accuse un retard sur la réalité de plusieurs mois.

L'alternative est pire.Le modèle traditionnel vous donne l'illusion de la stabilité tandis que l'écart grandit silencieusement sous la surface. Au moment où vous le remarquez, le système est inutilisable et la migration est un projet de six mois. Je préfère avoir des ajustements visibles, fréquents et petits plutôt que des dégradations invisibles et progressives.

Il y a aussi un argument de coût.Nous faisons fonctionner notre infrastructure d'agents sur un essaim Mac Studio, en passant par Mercury Flux — notre couche de routage de modèles qui délivre environ 18 milliards de tokens par mois à un coût global d'environ 0,07 $ par million de tokens. L'équivalent de détail serait de 20 000 à 200 000 $ par mois. Le trio d'agents ajoute un coût de calcul marginal à une infrastructure que nous exploitons déjà. Comparez cela au coût d'un projet de migration de système unique, ou au coût d'opportunité des rapports qui prennent des jours à concilier parce que les données se trouvent à cinq endroits différents.

L'économie n'est même pas proche.

Cela sera-t-il accepté ?

Je ne sais pas.

C'est un changement radical par rapport à la façon dont les organisations pensent aux systèmes. Nous sommes formés à croire que de bons systèmes sont des systèmes stables. Que le changement est un risque. Que l'objectif est de bien faire les choses du premier coup.

Mais "bien faire les choses du premier coup" est une fantaisie dans tout environnement qui croît, s'adapte ou traite avec des humains. La question n'est pas de savoir si votre système dérivera de la réalité. C'est de savoir si vous avez un mécanisme pour combler l'écart plus rapidement qu'il ne s'ouvre.

La plupart des organisations n'en ont pas. Elles ont des arriérés. Elles ont "nous le corrigerons dans la prochaine version". Elles ont des feuilles de calcul cachées et de la documentation de contournement qui vivent dans des fils Slack.

Je propose quelque chose de différent : accepter l'écart comme inévitable et construire la capacité de le combler en continu.

Certaines personnes détesteront cela. Cela menace le complexe industriel de la planification de projet. Cela fait de "l'implémentation" un coût opérationnel continu au lieu d'un projet capitalisable unique. Cela nécessite de faire confiance aux agents IA pour les changements de système que les humains contrôlaient auparavant.

Mais je fais fonctionner cela depuis un mois. L'écart qui prenait autrefois des trimestres à se combler se ferme maintenant en quelques heures. Les feuilles de calcul fantômes disparaissent parce que le système reflète réellement la réalité. La documentation est à jour car elle est générée, pas maintenue.

Ce n'est pas parfait. Mais c'est mieux que la spirale de la mort.

L'Implication Plus Large

Ce n'est pas seulement une question des systèmes internes de Mercury.

Le même schéma s'applique à chaque organisation luttant avec la transformation numérique. La raison pour laquelle tant de projets de transformation échouent n'est pas que la technologie ne fonctionne pas. C'est parce que l'écart entre le nouveau système et l'entreprise réelle se creuse toujours plus vite que l'équipe d'implémentation ne peut le combler.

Les agents IA changent l'économie de cette équation. Lorsque l'adaptation est automatisée et continue, l'écart devient gérable. Lorsqu'elle est manuelle et basée sur des projets, l'écart gagne toujours.

Les organisations qui comprendront cela en premier auront un avantage structurel. Pas parce que leurs systèmes sont mieux conçus, mais parce que leurs systèmes sont meilleurs pour devenir ce dont l'entreprise a réellement besoin.

C'est aussi pourquoi je ne m'inquiète pas de l'IA qui commoditise notre industrie.

Les 43 % de prospects qui tombent dans le fossé entre l'IA et l'humain ? Ce chiffre provient de la même observation. Les systèmes conçus pour des flux de travail idéaux manquent le comportement réel. Les entreprises qui capturent ces 43 % ne seront pas celles avec de meilleurs chatbots. Ce seront celles dont l'infrastructure s'adapte continuellement à la façon dont les humains travaillent réellement — pas à la façon dont les diagrammes de processus disent qu'ils devraient travailler.

C'est le pari que je fais.

Écrit depuis Hong Kong, où l'humidité est élevée et l'écart entre la climatisation et la réalité est d'environ 12 degrés.