Les agents IA sont largement surutilisés

Quatre-vingt-dix-neuf pour cent est le score d'autonomie le plus dangereux qu'un agent IA puisse afficher. À 99 %, les humains cessent de lire la piste d'audit, et les seuls cas qui leur parviennent encore sont les rares, ceux où les enjeux sont les plus lourds. Cinquante pour cent fait moins bonne figure sur une diapositive et se pilote plus facilement : chaque cas est lu, chaque correction enseigne le motif, et le système s'améliore de semaine en semaine.

Le discours commercial arrive d'habitude dans l'autre sens : des agents autonomes qui vont « révolutionner vos workflows ». Nous construisons des systèmes de données et géospatiaux, donc ces discours atterrissent chaque semaine, et l'attrait n'est pas feint. Les agents sont puissants. Ils sont aussi largement surutilisés, et la frontière est courte : un agent mérite son coût de mise en place là où les décisions sont fréquentes, à faible enjeu, et réversibles. Partout ailleurs, un simple appel LLM, ou un simple humain, est le meilleur outil.

Un agent décide. Un chatbot répond.

Un agent est un système d'IA qui perçoit son environnement, décide d'actions, les exécute de façon autonome, et apprend des retours. Un chatbot qui répond aux questions n'est pas un agent. Un système qui surveille votre pipeline de données, détecte les anomalies, recherche les causes racines et met la remédiation en file d'attente, lui, l'est.

La distinction compte parce que l'agentivité arrive avec une facture. Chaque décision qu'un système autonome prend est une décision que personne n'a prise, à la vitesse de la machine, en production. Cette complexité doit mériter sa place, décision après décision.

Là où les agents remboursent leur coût

Cinquante flux par jour

Supposez que votre équipe ingère chaque jour plus de 50 flux de données, couvrant l'inventaire, la tarification et les expéditions. Chaque flux demande une validation, et les avis d'échec tombent dans un canal Slack où un ingénieur les trie à la main. Au bout de quelques semaines, le canal contient les mêmes dix types d'échec, retitrés d'un fournisseur à l'autre.

Piloté par un LLM, un agent reprend ce triage :

• Lit les journaux des validations en échec
• Classe la panne : dérive de schéma, anomalie de données, ou bug en amont
• Agit : prévient le fournisseur, met la donnée en quarantaine, ou escalade vers l'ingénierie
• Journalise la décision pour revue

Le canal change de forme. Ce qui y tombe ensuite, ce sont les cas qui ont besoin d'une personne, pas les cas qui ressemblent à hier.

Pourquoi ça marche : les décisions sont fréquentes, des dizaines par jour, et le risque est bas parce que la mise en quarantaine d'une donnée est réversible. Le succès est aussi vérifiable, ce dont un agent a besoin. Une validation passe ou échoue.

L'enquête sur la télémesure impossible

Quand un véhicule rapporte une télémesure impossible, un saut de position soudain ou un pic de vitesse, quelqu'un doit décider si le boîtier mérite confiance. Vérifier la dérive GPS. Comparer les véhicules voisins. Regarder les motifs historiques. Puis trancher : signaler ou archiver.

Un agent mène cette enquête et renvoie une recommandation. Un humain garde la décision finale. Les étapes sont bien définies mais fastidieuses, c'est exactement là qu'un LLM se rembourse, et la revue humaine permanente capture les cas limites.

Le playbook qui traverse plusieurs systèmes

Les pannes de pipeline traversent toujours plusieurs systèmes. Les journaux vivent dans Datadog, les déploiements dans GitHub, les jobs dans Airflow, les mises à jour dans Slack. Un agent doté d'un outil par système peut dérouler le playbook de réponse tout seul, et la piste d'audit de tout ce qu'il a touché est offerte. La partie qui le rend sûr, c'est que les étapes existent déjà dans des runbooks. L'agent exécute un script approuvé. Il n'en invente pas un.

Les décisions qui doivent rester humaines

Tout ce que contient cette section échoue au même test, vu de l'autre direction.

Une décision prise une fois par trimestre, comme le choix du fournisseur de cloud ou de la base de données de référence, laisse à l'agent aucune occasion d'apprendre des retours. Le coût de mise en place ne se rembourse jamais. La parade : utiliser un LLM comme assistant de recherche, lui faire résumer les arbitrages, puis décider vous-même.

Puis, ensemble, l'enjeu lourd et la rareté. Imaginez une migration de pipeline qui coûte 200 000 $ et prend six mois. Rien dans l'erreur ne se rattrape à la vitesse, et les LLM ne raisonnent pas sur les facteurs d'organisation comme les compétences de l'équipe ou les relations fournisseurs. Ces décisions demandent un jugement humain, même quand il est plus lent.

Enfin, les problèmes sans retour clair. « Améliorez la conception de notre modèle de données. » Que veut dire « meilleur » ici, des requêtes plus rapides, ou un schéma qu'un nouvel arrivant peut lire ? Sans objectif mesurable, l'agent produit des résultats incohérents, parce que les agents ne s'améliorent qu'à l'endroit où il existe un retour. Si vous ne savez pas définir le succès, vous ne pouvez pas l'automatiser.

Choisissez le motif qui limite le rayon d'explosion

ReAct : penser, agir, observer, s'arrêter

def agent_loop(task: str, tools: dict, max_iterations: int = 8):
    context = task
    for _ in range(max_iterations):
        thought = llm.generate(f"Context: {context}\nWhat should I do next?")
        action = parse_action(thought)

        if action == "DONE":
            return thought

        observation = tools[action.name](action.args)
        context += f"\nThought: {thought}\nAction: {action}\nObservation: {observation}"

    raise TimeoutError("Agent didn't converge")

Employez ce motif quand le problème se déroule en plusieurs étapes avec des dépendances entre elles. Le plafond d'itérations et le timeout ne sont pas des détails d'implémentation. C'est la barrière de sécurité du motif, et le TimeoutError est le motif qui fonctionne comme prévu.

Un superviseur avec des ouvriers spécialistes

Un LLM superviseur décompose l'objectif et distribue les sous-tâches à des ouvriers spécialisés : l'un rapatrie les données, l'un analyse, l'un compose la réponse. Employez ce motif quand les étapes demandent des expertises ou des outils différents. Le rayon d'explosion reste petit parce que chaque ouvrier ne voit que sa propre part.

L'humain approuve d'abord

L'agent propose, l'humain approuve, et l'agent apprend de chaque refus. Employez ce motif quand les enjeux sont modérés et que vous construisez encore la confiance. C'est aussi le motif qui gagne le plus vite les sceptiques, parce que les relecteurs voient la qualité des décisions s'améliorer avant que l'autonomie ne s'étende. Chaque pas vers plus d'autonomie, c'est ce motif avec moins de réunions.

La règle des 80 %

Construisez des agents quand ils peuvent traiter 80 % des cas de façon autonome et que les 20 % restants disposent d'un chemin d'escalade clair. Cinquante pour cent est un bon point de départ et une mauvaise cible. En dessous de 80 %, vous exploitez une file d'attente, pas encore un agent ; les agents que nous construisons partent du chiffre qu'a produit le pilote. À 99 % avec des modes d'échec catastrophiques sur 1 %, ce que vous avez construit est un risque opérationnel portant un nom sympathique.

Des composants ennuyeux, choisis à dessein

Composant	Recommandation
LLM	Claude Sonnet pour les tâches à raisonnement lourd, Claude Haiku pour les appels d'outils sensibles à la latence
Orchestration	LangChain pour les workflows multi-outils complexes, boucles Python simples pour les motifs plus simples
Outils	API REST avec schémas JSON. Les LLM donnent de meilleurs résultats avec des interfaces sans ambiguïté
Supervision	Journaliser chaque décision avec son résultat

Commencez par le problème, pas par la technologie. Si la décision est fréquente, à faible enjeu, et réversible, un agent produit des gains mesurables. Sinon, un seul appel LLM est le meilleur choix, et vous y arriverez des semaines plus tôt.

En cas de doute, la bonne portée d'un agent est plus petite que ce que la démo a laissé croire.

AngoraTek construit des systèmes d'IA agentique pour les opérations de données. [Parlez-nous](/fr/#contact) si vous cherchez la place des agents dans votre workflow.