Le problème de la masse
De nombreux workflows d’IA actuels reviennent à utiliser une masse pour casser une noix.
La tâche est pourtant suffisamment simple : lire une feuille de calcul, vérifier de nouveaux enregistrements, enrichir quelques champs, classer une demande, créer un rapport, mettre à jour un CRM, envoyer une notification ou préparer une réponse à vérifier.
Mais au lieu de concevoir le processus, les équipes confient toute la tâche à un agent et lui demandent d’utiliser l’ordinateur comme une personne. L’agent ouvre des applications, parcourt des écrans, lit des lignes, décide de l’étape suivante, répète les mêmes instructions et dépense des tokens pour redécouvrir un workflow déjà connu.
Il faut également tenir compte de la disponibilité. Les outils d’IA les plus performants sont souvent utilisés dans des sessions limitées, avec des plafonds d’utilisation pratiques, des limites de débit ou des files d’attente. Si une équipe consomme cette capacité pour des tâches répétitives qu’un logiciel pourrait exécuter de manière déterministe, elle ne gaspille pas seulement des tokens. Elle mobilise un temps de modèle rare et précieux. Lorsqu’une tâche réellement complexe se présente, l’équipe peut alors devoir attendre de nouveau qu’une capacité se libère.
Cette approche peut être utile lorsque l’environnement est inconnu ou que la tâche est véritablement exploratoire. Mais ce n’est pas toujours la meilleure architecture pour un processus métier répétable.
La plupart des workflows de production ne sont pas des problèmes d’agents. Ce sont des problèmes d’automatisation avec des appels ponctuels à l’IA.
Un workflow est généralement plus structuré qu’il n’y paraît
Lorsqu’on les examine attentivement, de nombreux workflows d’IA suivent une structure prévisible.
Ils commencent par un déclencheur. Il peut être planifié : chaque matin, chaque vendredi, à la fin du mois ou après la clôture d’une période de reporting. Il peut aussi être événementiel : un e-mail arrive, un client envoie un formulaire, un enregistrement change dans une base de données, un ticket est créé ou un nouveau fichier est déposé dans un dossier.
Le workflow récupère ensuite des données d’entrée. Elles peuvent provenir d’une API, d’un CRM, d’un ERP, d’une feuille de calcul, d’un document, d’une application web, d’une base de données existante ou d’une combinaison de systèmes.
Puis il parcourt les données reçues. Il valide les enregistrements, filtre les cas, normalise les champs, applique des règles, vérifie les statuts, oriente le traitement selon certaines conditions et prépare les résultats.
Seules certaines étapes nécessitent réellement l’IA.
L’IA peut être nécessaire pour extraire le sens d’un texte non structuré, classer une demande, résumer des éléments probants, rédiger une réponse, comparer des documents, déterminer le chemin d’exception applicable ou générer une recommandation. Mais de nombreuses étapes environnantes sont déterministes. Elles devraient être gérées par du code, et non par un raisonnement répété.
Enfin, le workflow stocke ou transmet le résultat. Il met à jour une base de données, réécrit dans un CRM, crée un document, envoie un e-mail, ouvre une tâche, publie un message dans Slack ou alimente un tableau de bord.
Ce n’est pas une personne qui clique sur un écran. C’est un processus.
Les tokens d’exécution doivent être consacrés à l’intelligence
L’erreur coûteuse consiste à utiliser des appels de modèle pour une orchestration que le logiciel peut gérer directement.
Si, à chaque exécution, un agent doit lire les mêmes instructions, parcourir les mêmes écrans, inspecter les mêmes colonnes et décider de la même étape évidente, 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, les boucles, la validation, le routage, les nouvelles tentatives et le stockage
- utiliser des API et des connecteurs lorsque les systèmes exposent déjà des interfaces fiables
- appeler l’IA uniquement pour les étapes qui bénéficient de la compréhension du langage, de la génération, du raisonnement ou du jugement
- choisir le modèle adapté à chaque étape au lieu d’envoyer chaque tâche au modèle le plus puissant
- rendre visibles les traces, les coûts, la latence, les entrées, les sorties et les échecs
C’est ainsi que l’on économise des tokens. Pas seulement en utilisant des modèles moins coûteux, mais en supprimant entièrement les appels de modèle inutiles.
Dans les déploiements Guanta, cette architecture peut réduire considérablement l’utilisation des tokens, car le modèle n’est plus chargé d’exécuter l’ensemble du processus. L’entreprise paie pour l’intelligence dont elle a besoin, au moment où elle en a besoin, avec le modèle adapté à la tâche.
Avec le temps, certaines parties peuvent même ne plus nécessiter d’appels à des modèles externes. Des modèles plus petits, des classifieurs spécialisés, l’inférence locale, la mise en cache des décisions, les embeddings et le code traditionnel peuvent prendre en charge une part croissante du workflow. La plateforme doit permettre ces choix sans nécessiter de repenser le processus à chaque fois.
L’IA intervient aussi au moment de la conception
Cela ne signifie pas qu’il faut utiliser moins d’IA au total.
Cela signifie qu’il faut l’utiliser au bon endroit.
L’IA peut être extrêmement utile lors de la conception du workflow. Elle peut aider à traduire les exigences en code, générer des connecteurs, écrire des transformations de données, rédiger une logique de validation, créer de petits outils internes, produire des tests, expliquer des API existantes et accélérer la transformation d’un processus opérationnel complexe en logiciel.
Mais une fois le workflow connu, l’entreprise ne devrait pas continuer à payer un modèle pour générer encore et encore la même logique au moment de l’exécution.
Utilisez largement l’IA lors des phases de conception et de développement. Déployez ensuite le workflow sur une plateforme qui l’exécute de manière fiable. Au moment de l’exécution, appelez l’IA uniquement lorsque les données réelles nécessitent effectivement de l’intelligence.
Cette distinction est importante.
Les agents sont efficaces pour déterminer quoi faire lorsque le problème est ambigu. Les plateformes sont efficaces pour exécuter de manière fiable, répétée, sécurisée et observable un travail connu.
La meilleure architecture utilise les deux. L’IA aide à créer le workflow. La plateforme exécute le workflow. L’IA est appelée à l’intérieur du workflow uniquement aux endroits où elle crée un véritable effet de levier.
Pourquoi une plateforme est nécessaire
Les tâches répétables utilisant l’IA nécessitent plus que des prompts.
Elles nécessitent des connecteurs vers les systèmes métier. Elles nécessitent une exécution planifiée et événementielle. Elles nécessitent un état, des permissions, des nouvelles tentatives, des files d’attente, des journaux, des secrets, des étapes d’approbation humaine, une gestion des versions et des contrôles de déploiement.
Elles nécessitent également de l’observabilité.
Lorsqu’un workflow 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 d’IA
- combien de tokens ont été consommés
- combien de temps chaque étape a pris
- quels enregistrements ont échoué et pourquoi
- quelles sorties ont été écrites
- quels cas nécessitent une vérification humaine
Sans cette couche, l’automatisation par l’IA devient difficile à exploiter. Un utilisateur peut voir une réponse, mais l’organisation ne peut pas comprendre les coûts, la qualité, les modes d’échec ou l’état de santé du processus.
C’est pourquoi le véritable besoin est une plateforme : un espace pour connecter les applications, exécuter les processus, appeler l’IA de manière sélective, transmettre les résultats là où ils sont nécessaires et observer l’ensemble du système à tout moment.
Le rôle des ingénieurs déployés sur le terrain
L’IA peut contribuer à générer le code du workflow, mais quelqu’un doit toujours comprendre le processus réel.
C’est le rôle de l’ingénieur déployé sur le terrain.
Un FDE travaille au plus près du client et traduit la réalité opérationnelle en conception de workflows exécutables. Il identifie le déclencheur, les systèmes sources, les champs importants, les exceptions, les points d’approbation, les contraintes de sécurité et le résultat métier attendu.
Il détermine ce qui doit relever du code déterministe, là où l’IA est réellement utile, le modèle suffisamment performant, ce qui ne doit jamais être envoyé à un modèle et ce qui doit être journalisé à des fins d’audit et d’amélioration.
L’IA peut rédiger une première version. Les FDE la rendent exploitable en production.
C’est important, car les workflows réels regorgent de contexte qui n’apparaît pas clairement dans un ticket. Certaines actions ERP sont irréversibles. Certains champs sont sensibles. Certaines exceptions sont politiques. Certains échecs sont acceptables, tandis que d’autres perturbent les opérations. Certaines décisions peuvent être automatisées, alors que d’autres nécessitent l’intervention d’une personne.
La plateforme donne davantage de levier aux FDE. Au lieu de commencer chaque déploiement à partir d’un dépôt vide, ils peuvent s’appuyer sur des connecteurs réutilisables, des briques de workflow, 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épétable.
Cette combinaison évite deux écueils : les agents ouverts qui consomment trop de ressources au moment de l’exécution et les projets de conseil sur mesure qui ne deviennent jamais des fonctionnalités produit réutilisables.
Le bon 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 ne l’est pas.
Le travail connu doit devenir du logiciel. Le travail inconnu ou fortement lié au langage peut utiliser l’IA. Le travail répétitif doit s’exécuter sur une plateforme. Le travail sensible doit être soumis à des contrôles. Le travail coûteux doit être mesuré. Les échecs doivent être visibles. Les améliorations doivent se cumuler.
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 par l’IA ne sera pas un agent géant qui clique toute la journée dans chaque application. Ce seront des processus métier conçus sous forme de workflows, générés plus rapidement grâce à l’IA, exécutés par une plateforme, surveillés de bout en bout et pris en charge par des ingénieurs qui comprennent à la fois le client et le code.
C’est ainsi que les entreprises cessent d’utiliser une masse pour casser une noix.
Et c’est ainsi qu’elles paient pour l’IA dont elles ont réellement besoin.