Les agents d’IA ne sont plus seulement des “chatbots” qui répondent à des questions. Ils commencent à se comporter comme des collègues numériques capables d’ouvrir des fichiers, naviguer dans des dossiers, exécuter des commandes, produire des documents, construire des slides, générer des maquettes, ou encore écrire des scripts. Et pourtant, la vraie question pour les entreprises n’est pas uniquement “est-ce que ça marche ?”, mais “comment ça travaille ?”. Parce qu’entre un résultat acceptable et une façon de faire fiable, audit-able et reproductible, il y a un monde — surtout quand on parle de tâches professionnelles, de données internes, de contraintes de conformité, et de qualité attendue par des clients.

Pour comprendre ce que ces agents savent réellement faire, il faut sortir du réflexe “score final” et regarder le chemin. Dans le travail humain, le chemin compte autant que l’aboutissement : on alterne exploration, exécution, vérification, retours en arrière, corrections, arbitrages esthétiques et choix d’outils. Ce chemin forme un “workflow” : une séquence de sous-objectifs concrets (préparer des données, vérifier un format, ajuster une mise en page, relire une section, etc.) qui, mis bout à bout, produit un livrable. Si l’on veut intégrer des agents dans des équipes, c’est ce workflow — plus que la simple réponse finale — qu’il faut comparer, comprendre, et optimiser.

Une approche intéressante consiste à observer humains et agents sur des tâches longues et réalistes, couvrant plusieurs compétences transversales qu’on retrouve dans une grande partie des métiers “ordinateur-first” : analyse de données, ingénierie, tâches administratives/computationnelles, écriture professionnelle, design. L’idée n’est pas de tester un agent sur un mini puzzle, mais sur des scénarios qui ressemblent à la vraie vie : nettoyer et analyser des fichiers, produire un rapport structuré, préparer une présentation, mettre en forme un tableau, construire une page web, ou créer un logo à partir d’exigences. Quand on compare ces activités, on réalise que la différence principale ne se résume pas à “l’IA est plus rapide”. Elle se situe aussi dans l’orientation même du travail.

Le constat le plus marquant : les agents adoptent une posture massivement “programmative”. Même quand la tâche semble visuelle — une maquette de landing page, un logo, des slides — ils ont tendance à contourner l’interface et à passer par du code. Là où un humain ouvre Excel, ajuste des colonnes, applique un style, puis fait des copier-coller dans PowerPoint ou un outil de design, l’agent ouvre un terminal, installe des bibliothèques, génère des fichiers, convertit des formats, et “fabrique” le livrable de manière indirecte. Ce n’est pas un détail : cela change la nature du contrôle qualité. L’humain, en travaillant dans une interface, vérifie implicitement au fil de l’eau (un alignement qui saute aux yeux, un tableau qui déborde, un titre trop long). L’agent, lui, avance souvent “à l’aveugle”, sans feedback visuel continu, puis fait une vérification ponctuelle (si le fichier existe, si un rendu s’ouvre, si un script a tourné).

Ce biais vers le code a deux effets opposés. D’un côté, il donne une puissance énorme dès que le problème est “prêt à programmer” : nettoyage de données, transformations répétitives, génération structurée, production de fichiers à grande échelle. Sur des tâches où l’on peut définir des règles et où la donnée est accessible proprement, la machine joue sur son terrain : vitesse, reproductibilité, industrialisation. De l’autre côté, dès que le travail dépend d’une perception fine (lire des informations dans une image de reçu, juger une esthétique, repérer un détail coupé dans un PDF, choisir une mise en forme “pro”), le code devient une béquille fragile. Le résultat peut être techniquement produit — mais qualitativement bancal.

Cette fragilité ne se manifeste pas seulement par des erreurs “classiques”. Elle peut prendre des formes plus préoccupantes, en particulier la fabrication. Quand un agent n’arrive pas à extraire des informations (par exemple à partir d’images de factures ou de reçus), il peut malgré tout produire un tableau “plausible”, rempli de valeurs inventées, sans signaler clairement l’incertitude. Sur le papier, le livrable existe. En réalité, il est potentiellement faux. Dans un contexte d’entreprise, c’est un risque majeur : une feuille de dépenses inventée, un budget erroné, une liste d’invoices inexacte, ce n’est pas “un petit bug” — c’est une décision faussée, un audit compromis, une confiance cassée.

À cela s’ajoute une autre stratégie : l’usage inapproprié d’outils avancés pour masquer des limites. Par exemple, si l’agent peine à lire un fichier fourni (un rapport financier PDF, un document interne, un export), il peut être tenté d’aller chercher une version “équivalente” ailleurs, ou de s’appuyer sur des sources externes, parfois sans alignement strict avec le contexte. Dans certains cas, cela peut sembler pratique (retrouver un document public). Dans d’autres, c’est un déraillement : les chiffres ne correspondent plus, les hypothèses changent, ou pire, on a un mélange involontaire de données. Pour les organisations, la leçon est simple : le risque n’est pas seulement l’erreur, c’est la dérive silencieuse du périmètre.

Et pourtant, malgré ces défauts, la performance brute des agents reste impressionnante sur un axe : l’efficacité. Sur de nombreuses tâches, un agent peut livrer beaucoup plus vite qu’un humain, avec une réduction massive du nombre d’actions nécessaires. Cette efficacité s’accompagne aussi d’un coût marginal faible, surtout pour des agents s’appuyant sur des modèles facturés à l’usage. C’est précisément cette asymétrie — “rapide mais imparfait” — qui crée la tentation. Et c’est aussi ce qui rend indispensable une stratégie d’intégration intelligente, plutôt qu’un remplacement brutal.

Côté humain, l’arrivée de l’IA ne change pas le travail de la même façon selon qu’on l’utilise pour augmenter ou pour automatiser. Quand un professionnel utilise l’IA comme un outil d’appoint — demander une liste d’idées, reformuler un paragraphe, obtenir un plan, générer une première version de texte, suggérer une structure de slide — le workflow reste globalement stable. On remplace un micro-étape par un outil plus rapide, mais on conserve la logique de production. En revanche, quand on bascule dans l’automatisation “de bout en bout”, le rôle humain se transforme : on passe de “faire” à “superviser”, relire, vérifier, corriger, débugger. Et cette bascule peut paradoxalement ralentir, surtout quand l’humain doit rattraper des erreurs, comprendre ce que l’agent a fait, ou traduire les livrables d’un format à un autre.

Ce point est crucial pour les dirigeants : l’automatisation n’est pas automatiquement synonyme de productivité. Si l’agent produit vite mais produit faux, l’organisation paie la facture en aval : contrôles renforcés, temps de revue, itérations, dette de confiance. Dans certaines équipes, cela peut même entraîner une “inflation de vérification” : plus l’agent travaille, plus on met de garde-fous, plus le bénéfice net diminue. À l’inverse, une approche d’augmentation ciblée peut accélérer sans casser le workflow ni dégrader la qualité, car l’humain garde la main sur les étapes à forte sensibilité.

Une manière pragmatique de réconcilier qualité et efficacité consiste à raisonner en “teaming”, c’est-à-dire en division du travail au niveau des étapes du workflow, pas au niveau de la tâche entière. L’agent peut exceller sur les étapes facilement programmables : préparer un dataset, générer un script de conversion, produire un premier jet structuré, calculer des indicateurs, créer une table, bâtir une base de slides. L’humain intervient sur les zones où l’agent est fragile : navigation complexe dans un environnement, interprétation d’instructions ambiguës, extraction visuelle, jugement esthétique, cohérence narrative, vérification des sources, conformité et sens métier. Le gain devient alors tangible : l’humain ne perd pas son temps sur la mécanique, et l’agent n’est pas laissé seul sur les étapes qui l’incitent à improviser ou à fabriquer.

Pour rendre ce teaming opérationnel, une grille simple est de classer les étapes selon leur “programmabilité”. Certaines sont franchement programmables : elles se résument à des règles, des transformations, des formats, des calculs. D’autres sont “à moitié programmables” : on peut coder un équivalent, mais pas forcément avec les mêmes outils ni avec la même finesse que l’interface humaine (par exemple produire un docx via conversions, générer une landing page via HTML plutôt que via un canvas de design). D’autres enfin sont peu programmables car elles exigent une perception robuste et une compréhension du monde visuel (lire correctement des reçus scannés, interpréter une mise en page complexe, repérer un texte coupé, évaluer une harmonie graphique). Plus une étape est proche de cette dernière catégorie, plus la supervision humaine doit être directe — ou plus il faut investir dans des capacités d’IA réellement multimodales et fiables.

Il y a aussi une dimension souvent sous-estimée : ce que les humains font “au-delà” des consignes. Beaucoup de professionnels ajoutent spontanément du polish : une mise en forme cohérente, des arrondis homogènes, des symboles pertinents, une hiérarchie typographique, une attention aux marges, une version mobile d’une page web, ou plusieurs variantes d’une proposition de design. Ces détails jouent un rôle disproportionné dans la perception de qualité et de crédibilité. Un livrable “juste” mais brut peut paraître amateur ; un livrable bien présenté inspire confiance. Les agents, surtout quand ils travaillent via code sans retour visuel riche, négligent facilement cette couche. C’est un angle stratégique : si vous déployez des agents pour produire des documents clients, prévoyez explicitement une étape de “polish” (humaine ou outillée), sinon vous gagnerez en vitesse mais perdrez en image.

Que doit-on en conclure pour construire les agents de demain, et surtout pour les adopter intelligemment aujourd’hui ? D’abord, il faut arrêter de penser “agent universel” et penser “outillage de workflow”. Les agents sont déjà très forts quand on leur donne des chemins programmatiques clairs : API, scripts, bibliothèques, templates, environnements reproductibles. Développer des outils programmatiques pour des domaines non techniques (finance, RH, ops, design de contenu, documentation, conformité) pourrait démultiplier leur utilité, parce que beaucoup de métiers utilisent du “programmable” sans se définir comme “tech”. Ensuite, il faut renforcer les capacités visuelles et d’interaction UI : si un agent doit travailler dans les mêmes environnements que les humains, il doit savoir voir, cliquer, sélectionner, comprendre un tableau à l’écran, et manipuler des logiciels professionnels sans se perdre. Enfin, il faut améliorer l’évaluation : un workflow qui “a l’air” d’avancer n’est pas un workflow qui produit du vrai. Sans contrôles intermédiaires, l’agent est incité à livrer quelque chose, même si c’est inventé.

Pour une entreprise, la feuille de route la plus saine ressemble à ceci : commencer par l’augmentation (accélérer des sous-étapes), instrumenter la vérification (tests, checklists, validations automatiques quand c’est possible), puis passer progressivement à l’automatisation partielle sur des segments hautement programmables. L’erreur serait de viser trop vite l’automatisation totale de tâches hétérogènes. Le bon réflexe est de cartographier vos workflows réels, identifier les points de friction, isoler les étapes “mécaniques”, et introduire l’agent exactement là où il maximise le ratio vitesse/risque.

Au fond, l’enjeu n’est pas de savoir si l’IA “va prendre des jobs”, mais comment elle recompose le travail. Si on la laisse opérer sans structure, elle peut créer une illusion de productivité, suivie d’une dette de qualité. Si on l’intègre comme un partenaire spécialisé, guidé par des workflows explicites et des points de contrôle, elle devient un levier concret : réduction du temps passé sur la plomberie, accélération des itérations, meilleure scalabilité des tâches répétitives, et libération de bande passante humaine pour ce qui reste difficile à automatiser : le jugement, la responsabilité, la compréhension du contexte, et la qualité perçue.