Le problème du marteau-pilon
De nombreux flux de travail IA donnent aujourd’hui l’impression d’utiliser un marteau-pilon pour casser une noix.
La tâche est assez simple : lire un tableur, vérifier de nouveaux enregistrements, enrichir quelques champs, classer une requête, créer un rapport, mettre à jour un CRM, envoyer une notification ou préparer une réponse pour révision.
Mais au lieu de concevoir le processus, les équipes confient le travail entier à un agent et lui demandent d’opérer l’ordinateur comme une personne. L’agent ouvre des applications, clique dans les écrans, lit des lignes, décide de l’étape suivante, répète les mêmes instructions et dépense des tokens à redécouvrir un flux de travail déjà connu.
Il y a aussi un coût d’accès. Les outils d’IA les plus performants sont souvent utilisés dans des sessions limitées, avec des quotas pratiques, des limites de débit ou des files d’attente. Si une équipe consomme cette capacité pour des tâches répétitives que le logiciel pourrait exécuter de façon déterministe, ce n’est pas seulement du gaspillage de tokens. C’est l’utilisation d’un temps de modèle rare et à forte valeur. Puis, quand une tâche réellement difficile apparaît, l’équipe peut de nouveau être en attente de capacité.
Cela peut être utile lorsque l’environnement est inconnu ou que la tâche est vraiment exploratoire. Ce n’est pas toujours la meilleure architecture pour un processus métier répétable.
La plupart des flux de travail en production ne sont pas des problèmes d’agent. Ce sont des problèmes d’automatisation avec des appels IA occasionnels.
Un flux de travail est généralement plus structuré qu’il n’y paraît
À y regarder de plus près, beaucoup de flux de travail IA suivent une forme prévisible.
Ils commencent par un déclencheur. Parfois il est planifié : chaque matin, chaque vendredi, en fin de mois ou après la clôture d’une fenêtre de reporting. Parfois il est événementiel : un e-mail arrive, un client soumet un formulaire, un enregistrement change dans une base, un ticket est créé ou un nouveau fichier apparaît dans un dossier.
Ensuite, le flux reçoit des données d’entrée. Celles-ci peuvent provenir d’une API, d’un CRM, d’un ERP, d’un tableur, d’un document, d’une application web, d’une base existante ou d’une combinaison de systèmes.
Puis il itère sur l’entrée. Il valide des enregistrements, filtre des cas, normalise des champs, applique des règles, vérifie des statuts, bifurque selon des conditions et prépare des sorties.
Seules quelques étapes nécessitent réellement de l’IA.
L’IA peut être nécessaire pour extraire du sens d’un texte non structuré, classer une demande, résumer des éléments de preuve, rédiger une réponse, comparer des documents, décider quel chemin d’exception s’applique ou générer une recommandation. Mais de nombreuses étapes alentours sont déterministes. Elles devraient être du code, pas du raisonnement répété.
Enfin, le flux stocke ou livre le résultat. Il met à jour une base, écrit dans un CRM, crée un document, envoie un e-mail, ouvre une tâche, publie sur Slack ou expose un tableau de bord.
Ce n’est pas une personne qui clique dans des écrans. C’est un processus.
Les tokens d’exécution doivent être dépensés pour l’intelligence
L’erreur coûteuse est d’utiliser des appels aux modèles pour de l’orchestration que le logiciel peut gérer directement.
Si chaque exécution demande à un agent de lire les mêmes instructions, naviguer les mêmes écrans, inspecter les mêmes colonnes et décider du même pas évident suivant, l’entreprise paie pour une coordination répétée, pas pour de l’intelligence.
Le meilleur modèle est simple :
- utiliser du code déterministe pour les déclencheurs, boucles, validations, routage, retries et stockage
- utiliser des API et des connecteurs quand les systèmes exposent déjà des interfaces fiables
- appeler l’IA uniquement pour les parties qui tirent avantage de la compréhension du langage, de la génération, du raisonnement ou du jugement
- choisir le bon modèle pour chaque étape au lieu d’envoyer chaque tâche au modèle le plus puissant
- conserver des traces, coûts, latences, entrées, sorties et échecs visibles
C’est là que se trouvent les économies de tokens. Non seulement en choisissant des modèles moins coûteux, mais en supprimant entièrement des appels modèles inutiles.
Dans les déploiements Guanta, cette architecture peut réduire de façon drastique l’utilisation des tokens parce que le modèle n’est plus sollicité pour exécuter tout le processus. L’entreprise paie pour l’intelligence dont elle a besoin, quand elle en a besoin, avec le modèle adapté à la tâche.
Avec le temps, certaines parties peuvent ne plus nécessiter d’appels externes au modèle du tout. Des modèles plus petits, des classifieurs spécialisés, de l’inférence locale, des décisions mises en cache, des embeddings et du code conventionnel peuvent prendre en charge une plus grande partie du flux. La plateforme doit permettre ces choix sans redessiner le processus à chaque fois.
L’IA a aussi sa place au moment de la construction
Cela ne signifie pas utiliser moins d’IA au total.
Cela signifie utiliser l’IA au bon endroit.
L’IA peut être extrêmement utile lors de la construction du flux de travail. Elle peut aider à traduire des exigences en code, générer des connecteurs, écrire des transformations de données, rédiger la logique de validation, créer de petits outils internes, produire des tests, expliquer des API héritées et accélérer la transformation d’un processus opérationnel désordonné en logiciel.
Mais une fois le flux connu, l’entreprise ne devrait pas continuer à payer un modèle pour régénérer la même logique encore et encore à l’exécution.
Utilisez beaucoup l’IA au moment de la conception et de la construction. Puis déployez le flux sur une plateforme qui l’exécute de manière fiable. À l’exécution, appelez l’IA uniquement là où les données en direct nécessitent réellement de l’intelligence.
Cette distinction a de l’importance.
Les agents sont bons pour déterminer quoi faire quand le problème est ambigu. Les plateformes sont bonnes pour faire un travail connu de manière fiable, répétée, sécurisée et observable.
La meilleure architecture combine les deux. L’IA aide à créer le flux. La plateforme exécute le flux. L’IA est invoquée à l’intérieur du flux seulement aux points où elle crée une réelle levée.
Pourquoi une plateforme est importante
Le travail IA répétable a besoin de plus que de simples prompts.
Il a besoin de connecteurs vers les systèmes métier. Il a besoin d’exécution planifiée et événementielle. Il a besoin d’état, de permissions, de retries, de files d’attente, de logs, de secrets, d’étapes d’approbation humaine, de versioning et de contrôles de déploiement.
Il a aussi besoin d’observabilité.
Quand un flux s’exécute, l’équipe doit pouvoir voir ce qui s’est passé :
- ce qui a déclenché l’exécution
- quels enregistrements d’entrée ont été traités
- quels systèmes ont été consultés
- quel modèle a été utilisé pour chaque étape IA
- combien de tokens ont été dépensés
- combien de temps chaque étape a pris
- quels enregistrements ont échoué et pourquoi
- quelles sorties ont été écrites
- quels cas nécessitent une revue humaine
Sans cette couche, l’automatisation IA devient difficile à exploiter. Un utilisateur peut voir une réponse, mais l’organisation ne peut pas comprendre le coût, la qualité, les modes de défaillance ou la santé du processus.
C’est pourquoi le besoin réel est une plateforme : un endroit pour connecter des applications, exécuter des processus, appeler l’IA de manière sélective, livrer les résultats là où ils sont nécessaires et observer tout le système en continu.
Où s’insèrent les ingénieurs déployés en avant
L’IA peut aider à générer le code du flux, mais quelqu’un doit quand même comprendre le processus réel.
C’est le rôle de l’ingénieur déployé au plus proche du client (FDE).
Un FDE se place près du client et traduit la réalité opérationnelle en une conception de flux exécutable. Il identifie le déclencheur, les systèmes sources, les champs pertinents, les exceptions, les points d’approbation, les contraintes de sécurité et le résultat métier attendu.
Il décide ce qui doit être du code déterministe, où l’IA est réellement utile, quel modèle est suffisant, ce qui ne doit jamais être envoyé à un modèle et ce qui doit être journalisé pour audit et amélioration.
L’IA peut écrire la première version. Les FDE rendent cela prêt pour la production.
Cela compte parce que les flux réels sont pleins de contexte qui n’est pas évident à partir d’un ticket. Certaines actions ERP sont irréversibles. Certains champs sont sensibles. Certaines exceptions sont politiques. Certaines erreurs sont acceptables, d’autres interrompent les opérations. Certaines décisions peuvent être automatisées, d’autres nécessitent un humain en boucle.
La plateforme donne de la levée aux FDE. Plutôt que de démarrer chaque déploiement depuis un dépôt vide, ils peuvent utiliser des connecteurs réutilisables, des primitives de flux, de l’observabilité, des contrôles de sécurité et un développement assisté par l’IA. Le FDE traduit le processus. La plateforme rend l’implémentation réutilisable.
Cette combinaison évite deux pièges : des agents ouverts qui dépensent trop à l’exécution et des projets de conseil sur mesure qui ne deviennent jamais une capacité produit réutilisable.
Le meilleur modèle mental
L’objectif n’est pas de remplacer chaque agent par un script rigide.
L’objectif est de séparer ce qui est connu de ce qui est inconnu.
Le travail connu doit devenir du logiciel. Le travail inconnu ou lourd en langage peut utiliser l’IA. Le travail répété doit s’exécuter sur une plateforme. Le travail sensible doit bénéficier de contrôles. Le travail coûteux doit être mesuré. Les échecs doivent être visibles. Les améliorations doivent se compounding.
Pour de nombreuses entreprises, c’est la couche manquante entre les démonstrations d’IA et la valeur en production.
L’avenir de l’automatisation IA ne sera pas un agent géant cliquant toute la journée dans chaque application. Ce seront des processus métier conçus comme des flux de travail, générés plus rapidement avec l’IA, exploités par une plateforme, surveillés de bout en bout et soutenus par des ingénieurs qui comprennent à la fois le client et le code.
C’est ainsi que les entreprises arrêtent d’utiliser un marteau-pilon pour casser une noix.
Et c’est ainsi qu’elles paient pour l’IA dont elles ont réellement besoin.