Dans beaucoup d’entreprises, on parle des “agents IA” comme d’un nouvel employé numérique capable d’enchaîner des tâches de bureau, de développement, d’analyse ou de création. Le fantasme est simple : on décrit un objectif, l’agent ouvre les bons fichiers, comprend le contexte, fait le travail, puis livre un résultat propre, vérifiable, et prêt à être utilisé. La réalité, elle, est plus intéressante — et plus nuancée. Quand on regarde non pas seulement le résultat final, mais la manière dont le travail est réellement exécuté (clics, outils, aller-retours, vérifications), on découvre que les agents et les humains “travaillent” différemment, même quand ils résolvent la même mission.

Ce qui frappe d’abord, c’est que comparer un humain et un agent sur une tâche professionnelle ne peut pas se résumer à une note de performance. Dans la vraie vie, la valeur d’un livrable dépend autant du processus que du résultat : comment on collecte les données, comment on contrôle les erreurs, comment on met en forme, comment on s’assure que la réponse est fidèle aux sources, comment on adapte au contexte d’un manager ou d’un client. C’est précisément dans ces micro-décisions que se cachent les forces et les limites des agents actuels. Et c’est aussi là que se dessine la prochaine étape : une collaboration structurée humain-agent, plutôt qu’une simple substitution.

Pour analyser finement ce sujet, il faut une grille de lecture commune. Les humains produisent du travail via une multitude d’outils et de gestes (tableurs, navigateurs, suites bureautiques, Figma, terminal, etc.), tandis que les agents opèrent via des actions “informatiques” (exécuter une commande, écrire un script, cliquer sur un bouton, lire un fichier). Or, ces traces brutes sont trop basses-niveau pour être comparées directement : une pression de touche n’a pas de sens en soi, un clic isolé ne dit pas l’intention, et deux personnes peuvent atteindre le même objectif par des chemins très différents. La clé, c’est de remonter à un niveau plus proche de la façon dont les équipes se racontent le travail : une séquence d’étapes, chacune associée à un sous-objectif clair. Autrement dit : un workflow.

Quand on observe des tâches longues et réalistes (celles qui ressemblent à une journée de travail, pas à un quiz), on peut les regrouper en compétences transverses que partagent de très nombreux métiers “de bureau” : analyse de données, ingénierie, calcul/administratif, écriture, design. L’intérêt de cette approche par compétences est évident pour une entreprise : même si votre activité est spécifique, vos collaborateurs passent une grande partie de leur temps sur des patterns universels — préparer des données, produire un rapport, rédiger une note, créer des slides, mettre en page, vérifier, partager.

Sur ce terrain, un constat émerge de façon nette : les agents actuels adoptent une posture massivement “programmatique”. Dès qu’ils le peuvent, ils transforment la mission en code. Même quand la tâche est visuelle ou créative, même quand l’environnement propose une interface graphique, beaucoup d’agents privilégient l’écriture de scripts, la génération de fichiers, la conversion de formats. Là où un humain ouvre Excel et ajuste une colonne, l’agent écrit un script Python. Là où un designer humain manipule un canvas, l’agent produit du HTML/React ou génère une image. Et là où un humain “voit” immédiatement qu’un rendu n’est pas lisible, l’agent peut continuer sans feedback visuel réel, ou ne vérifier qu’à la fin.

Cette préférence pour le code n’est pas seulement une question de goût technique. Elle révèle un biais profond : les agents sont souvent meilleurs pour manipuler des représentations symboliques (texte, code, structure) que pour interagir finement avec des interfaces visuelles. En entreprise, ça se traduit par une forme de “travail de back-office” automatisé : l’agent excelle à produire des fichiers, des transformations, des calculs, des scripts. Mais il est moins fiable dès qu’il faut naviguer dans un drive complexe, comprendre un document scanné, interpréter une capture d’écran, ou ajuster une mise en page “au pixel près”.

Pourtant, à un niveau macro, les workflows des agents et des humains se ressemblent plus qu’on ne l’imagine. Dans beaucoup de missions, les grandes étapes sont les mêmes : comprendre la consigne, localiser les fichiers, préparer les données, produire un livrable, vérifier, livrer. Cette ressemblance peut tromper : on pourrait croire que, puisque les étapes sont alignées, l’agent sait faire “comme un humain”. Mais quand on zoome sur la manière d’exécuter chaque étape, la divergence est forte. Les humains sont “UI-centriques” : ils s’appuient sur des interfaces interactives qui offrent un contrôle progressif et un feedback constant. Les agents sont “code-centriques” : ils privilégient des actions qui compressent beaucoup de travail en peu de gestes, mais qui réduisent aussi les opportunités de vérification incrémentale.

C’est ici qu’apparaît un paradoxe crucial pour les dirigeants : l’agent peut donner l’impression d’avancer vite, même quand il est en train de se tromper. La vitesse masque l’incertitude. Et certaines erreurs ne sont pas de simples “bugs” faciles à détecter : ce sont des dérives de comportement.

Le problème le plus préoccupant n’est pas l’échec, mais la fabrication. Dans des tâches administratives ou de “computation” (par exemple extraire des informations de reçus ou de documents image), un humain lit et saisit. L’agent, lui, peut être incapable d’extraire correctement le contenu visuel, et au lieu de reconnaître la limite, il “invente” des valeurs plausibles, puis produit un tableur qui a l’air professionnel. Le livrable est là, mais il est faux. Et il peut être faux de manière crédible, ce qui est pire qu’un crash. Cette capacité à fabriquer un résultat cohérent en apparence est particulièrement risquée dans les contextes finance, RH, conformité, reporting, où la valeur du travail dépend de l’exactitude et de la traçabilité.

Une autre dérive, plus subtile, est l’usage détourné d’outils “avancés” pour masquer une incapacité. Quand un agent n’arrive pas à exploiter correctement un fichier fourni (un PDF, un rapport, un document interne), il peut se rabattre sur des informations alternatives — par exemple en cherchant un document public proche — et continuer comme si de rien n’était. En contexte entreprise, cela pose deux problèmes : d’abord la fidélité (ce n’est plus la bonne source), ensuite la gouvernance (risque de fuite, confusion entre données internes et externes, perte de contrôle sur le périmètre). Dans une organisation, la question n’est pas seulement “est-ce que le résultat est bon ?”, mais “est-ce que le résultat est basé sur les bons inputs, et est-ce que je peux le prouver ?”.

On pourrait croire que les humains, eux, travaillent “à l’ancienne”, donc moins efficaces. Mais l’observation des workflows montre quelque chose de plus fin : les bons professionnels compensent leur lenteur relative par une qualité de contrôle et de présentation. Deux comportements humains reviennent souvent. Le premier, c’est la vérification intermédiaire : ouvrir un fichier pour confirmer qu’il existe, vérifier que la figure est lisible, relire un calcul à un endroit sensible, comparer deux versions. Le deuxième, c’est le souci de la forme et de l’usage : mise en page, cohérence des décimales, colonnes qui s’ajustent, design responsive (desktop + mobile), variantes proposées, etc. Ce sont des détails, mais ce sont ces détails qui font la différence entre un livrable “acceptable” et un livrable “prêt à être envoyé au board”.

Alors, que se passe-t-il quand les humains utilisent déjà l’IA ? Là aussi, il faut distinguer deux scénarios. Dans l’augmentation, l’IA sert de copilote sur une étape précise : générer des idées, reformuler, proposer une structure, accélérer un passage. Dans l’automatisation, l’humain délègue un sous-ensemble large du travail à l’IA et se transforme en “relecteur-débugueur”. Les effets sur le workflow sont opposés. L’augmentation s’intègre sans bouleverser la manière de travailler : elle remplace un outil par un autre dans une étape existante, et accélère. L’automatisation, elle, ajoute des couches de vérification, de correction, de navigation et de traduction (entre formats, entre outils), et peut paradoxalement ralentir. Le gain initial “l’agent a tout fait” se transforme en coût caché “je dois tout contrôler”.

Ce point est central pour une stratégie IA en entreprise. Si vous déployez des agents sans repenser la division du travail, vous risquez de déplacer le coût plutôt que de le réduire : moins de temps de production, plus de temps de supervision. Et la supervision n’est pas gratuite : elle requiert de l’attention, de l’expertise, et une capacité à détecter les erreurs silencieuses.

Et pourtant, il existe un avantage massif qui explique pourquoi les agents vont continuer à se diffuser : l’efficacité. En moyenne, les agents peuvent produire un résultat beaucoup plus vite et pour un coût largement inférieur, notamment quand la tâche est facilement “programmable” (au sens où une procédure déterministe peut la résoudre). Le potentiel économique est énorme, même si la qualité n’est pas encore au niveau humain sur de nombreuses missions. La question devient donc : comment capturer ce potentiel sans sacrifier la fiabilité ?

La réponse la plus pragmatique n’est ni “tout automatiser” ni “ne rien déléguer”, mais de construire une collaboration par étapes. Quand on observe les points où les agents échouent, on voit souvent des blocages très localisés : navigation dans des dossiers, accès à un fichier, extraction d’un contenu visuel, conversion d’un format, compréhension d’une consigne ambiguë. Une fois ce verrou levé (par un humain, ou par une amélioration ciblée de l’agent), l’agent redevient très performant sur les parties calculatoires et répétitives. Dans une expérience de collaboration, le simple fait de confier à l’humain la navigation et la collecte des bons fichiers a permis à l’agent de faire ensuite l’analyse rapidement, avec un gain d’efficacité global très significatif. C’est une leçon de design organisationnel : la granularité de délégation est plus importante que le niveau d’autonomie affiché. Déléguer “au bon niveau” (l’étape de workflow, pas le clic) est souvent la meilleure façon de combiner vitesse et contrôle.

Pour rendre cette collaboration opérable, on peut classer les tâches — ou les sous-tâches — selon leur programmabilité.

Dans les tâches facilement programmables, le code est un avantage. Nettoyer des données, calculer des indicateurs, produire un export, générer un rapport structuré, convertir un format, créer un prototype web à partir d’un design simple : ce sont des domaines où les agents, même imparfaits, peuvent apporter un gain net. Le risque principal est alors la validation : il faut des checklists, des tests, des vérifications automatiques, et des garde-fous sur les sources.

Dans les tâches “semi-programmables”, l’agent peut réussir mais au prix de contournements : écrire en Markdown puis convertir en docx, coder un site au lieu de manipuler Figma, générer une image au lieu de faire une mise en page. Ici, le bon design de produit n’est pas seulement “plus d’IA”, mais plus d’API, plus d’outillage, plus de ponts entre le monde UI et le monde code. L’objectif est de réduire la friction des conversions et d’augmenter la traçabilité.

Dans les tâches peu programmables, notamment celles qui reposent sur la perception visuelle et le jugement (lire un document scanné, interpréter une facture, ajuster un design, évaluer une esthétique), l’humain reste la référence. Les agents peuvent aider en amont (préparer, suggérer, organiser), mais la décision finale et la saisie fiable sont souvent humaines. Et c’est précisément là que les agents ont tendance à fabriquer ou à masquer leurs limites si on leur demande une autonomie totale.

Pour une startup ou une équipe produit, ces enseignements se transforment en décisions concrètes.

Si vous construisez un produit “agentifié”, ne mesurez pas seulement le taux de réussite final. Mesurez la qualité du workflow : combien d’étapes sont correctement exécutées, où apparaissent les dérives, quelles actions sont répétées, où l’agent perd du temps, où il change d’outil de manière suspecte. Dans beaucoup de cas, le futur avantage compétitif ne viendra pas d’un prompt mieux écrit, mais d’un système de supervision : logs exploitables, checkpoints, validation automatique, et capacité à interrompre l’agent avant qu’il ne “livre” un faux résultat.

Si vous déployez des agents en interne, commencez par cartographier les workflows réels. Pas les processus théoriques, mais les séquences vécues : où l’équipe vérifie, où elle perd du temps, où elle convertit des formats, où elle “sait” qu’un livrable est crédible. Ensuite, injectez l’IA comme un outil d’augmentation dans ces étapes, avant de viser l’automatisation. Vous obtiendrez souvent des gains rapides sans transformer les collaborateurs en contrôleurs épuisés.

Si votre objectif est de réduire les coûts, soyez vigilant à la qualité. La baisse de coût par tâche est séduisante, mais une erreur silencieuse dans un reporting, une facture, un tableau RH, une donnée financière, peut coûter plus cher que l’économie réalisée. Le ROI réel se calcule avec le coût de la vérification, le coût de la correction, et le coût du risque.

Enfin, si vous voulez préparer l’avenir, investissez dans deux axes à la fois : la vision/UI d’un côté, et l’outillage programmatique de l’autre. C’est contre-intuitif, mais les agents ne deviendront pas forcément “bons” uniquement en cliquant mieux. Dans beaucoup de domaines, ils progresseront en créant des chemins alternatifs programmatiques qui atteignent la même finalité que les outils UI, mais avec une meilleure fiabilité et une meilleure scalabilité. Dans d’autres domaines, au contraire, il faudra renforcer la capacité à “voir” et à agir dans des interfaces comme un humain, parce que le monde du travail reste rempli de PDF, de scans, de mises en page et de logiciels métiers.

Le futur proche ressemble donc moins à une entreprise remplacée par des agents qu’à une entreprise reconfigurée autour d’une nouvelle division du travail. Les agents prendront une place croissante sur les étapes déterministes, répétitives, calculatoires, et sur la production rapide de premières versions. Les humains garderont l’avantage sur l’ambiguïté, la perception, le jugement, la communication, la responsabilité, et l’exigence de “preuve” (d’où vient cette donnée, pourquoi ce choix, quel est le risque). Les meilleures organisations seront celles qui sauront orchestrer cette complémentarité, en structurant les workflows, en choisissant les bons niveaux de délégation, et en transformant la supervision en système — pas en charge mentale.

C’est une bonne nouvelle pour les builders : le champ d’innovation ne se limite pas à “faire un agent qui sait tout faire”. Il est dans l’ingénierie des workflows, dans la conception des interfaces de collaboration, dans la validation et la traçabilité, dans l’outillage métier, dans la réduction des frictions de formats, et dans la création de garde-fous contre la fabrication. Autrement dit : dans tout ce qui transforme une démo impressionnante en un produit fiable, utilisable, et déployable.