Manager des humains et des agents : qui décide, qui vérifie, qui assume ?

À mesure que les agents IA passent de la suggestion à l'action, le problème du manager change de nature. Il ne s'agit plus seulement de répartir le travail entre des personnes, mais de définir ce qu'une machine peut décider seule, ce qui doit être vérifié, quand un humain doit reprendre la main et qui reste responsable du résultat.

Les cas disponibles ne dessinent pas un modèle unique. Ils font toutefois apparaître une ligne de partage utile : plus une décision est réversible, observable et bornée, plus son exécution peut être déléguée ; plus elle est difficile à annuler, ambiguë ou porteuse de conséquences importantes, plus l'autorité humaine doit rester explicite.

C'est probablement là que se situe l'une des principales évolutions du management à l'ère des agents. Le manager ne doit ni tout valider, au risque de devenir le nouveau goulot d'étranglement, ni « laisser faire l'IA » au nom de l'autonomie. Son travail consiste de plus en plus à concevoir le système de décision dans lequel humains et agents opèrent.

En bref

• •Plusieurs entreprises font déjà une distinction explicite entre ce que l'agent produit, ce que l'humain vérifie et ce qu'il reste seul habilité à décider. Ce signal apparaît dans l'engineering, le support, les opérations et les RH.
• •Le cas Doctolib est particulièrement intéressant : l'entreprise distingue les décisions réversibles, que les product builders peuvent prendre sans attendre un arbitrage, des décisions irréversibles qui restent du ressort du Product Manager.
• •Cela ne signifie pas que toute décision réversible devrait être automatisée, ni qu'un humain devrait approuver chaque sortie d'IA. L'autonomie dépend aussi du coût de l'erreur, de sa détectabilité, du périmètre touché et de la capacité à revenir en arrière.
• •La responsabilité ne peut pas être remplacée par une validation mécanique. Pour les systèmes d'IA à haut risque, le cadre européen prévoit des exigences de supervision humaine ; le NIST recommande de documenter explicitement les rôles de supervision, les responsabilités, les procédures d'escalade et les mécanismes d'arrêt.
• •Manager des agents ne consiste pas à leur donner un pourcentage abstrait d'autonomie. Il faut leur donner un mandat délimité, des droits d'action, des critères de réussite, des seuils d'escalade et un responsable humain identifiable.

Le manager ne distribue plus seulement des tâches : il distribue des droits de décision

Avec un copilote classique, la frontière semblait simple : la machine proposait, l'humain travaillait.

Avec un agent capable de chercher de l'information, modifier une base de données, écrire du code, fermer un ticket, préparer une réponse client ou déclencher un workflow, cette frontière devient insuffisante. Deux agents utilisant le même modèle peuvent avoir des niveaux d'autonomie radicalement différents. L'un rédige un brouillon que personne ne verra avant validation. L'autre modifie directement un système de production.

La bonne question n'est donc pas « notre agent est-il autonome ? », mais : « sur quelles décisions possède-t-il une autorité d'action, dans quelles limites et sous quel contrôle ? »

Cette distinction apparaît déjà dans plusieurs cas observés. Chez Stripe, d'après un témoignage recueilli par TPC, un agent peut intervenir comme premier reviewer de code, avant le passage humain. Chez Alan, des non-ingénieurs peuvent produire des modifications, mais la décision de merger reste du côté engineering. Chez Finary, les agents produisent des composants, mais le développeur conserve le dernier mot.

Ces organisations n'appliquent pas toutes la même méthode. Elles convergent toutefois sur un principe : production, vérification et décision finale peuvent être distribuées entre plusieurs acteurs différents.

C'est un changement important pour le management. Hier, déléguer signifiait souvent donner un objectif à une personne et lui attribuer une responsabilité. Demain, le manager doit aussi définir :

• •ce que l'agent peut voir ;
• •ce qu'il peut modifier ;
• •les décisions qu'il peut prendre ;
• •le montant, le volume ou le périmètre jusqu'auquel il peut agir ;
• •les preuves qu'il doit produire ;
• •les situations dans lesquelles il doit s'arrêter ;
• •la personne vers laquelle il doit escalader.

L'autonomie devient une propriété du workflow, et non une caractéristique générale de l'outil.

Doctolib : la distinction la plus intéressante n'est peut-être pas humain versus IA, mais réversible versus irréversible

Parmi les organisations étudiées, Doctolib fournit l'un des cadres les plus directement utilisables par un manager.

L'entreprise a redéfini « qui prend la décision » dans son organisation produit. Le PM conserve les décisions qualifiées d'irréversibles — priorités entre projets, certains choix légaux ou structurants — tandis que les product builders peuvent décider de sujets réversibles tels que le traitement d'un edge case ou certains arbitrages d'interface. La règle rapportée est pragmatique : lorsqu'une décision peut être annulée par un revert de pull request, inutile d'attendre systématiquement le PM.

Ce que ce cas montre réellement : une organisation peut augmenter l'autonomie de ses contributeurs, humains ou augmentés par des agents, en faisant descendre certaines décisions lorsque leur coût de réversibilité est faible.

Ce qu'il ne montre pas : que toute décision techniquement réversible est sans conséquence, ni que le cadre serait transposable tel quel au recrutement, à la finance ou au support client. Il n'existe pas non plus de mesure permettant d'attribuer un gain de productivité précis à cette seule règle de décision.

Une décision devient un meilleur candidat à une autonomie agentique lorsqu'elle cumule plusieurs propriétés.

La réversibilité n'est donc pas une règle suffisante. C'est le premier axe d'une matrice de délégation.

« Human in the loop » ne veut pas dire mettre un humain devant chaque bouton

Une réaction fréquente aux risques des agents consiste à ajouter une validation humaine partout. Elle rassure. Mais elle peut aussi recréer exactement le problème que l'automatisation devait résoudre.

Dans plusieurs organisations où les agents produisent davantage, le goulot se déplace vers la review, les évaluations et la décision. Anthropic est présenté comme un cas où la production de code augmente suffisamment pour déplacer la contrainte vers la décision et la merge queue. Alan assume également que la review devient un point de contrôle central.

Une analyse du secteur du conseil formule le même enjeu sous un autre angle : lorsque la production assistée par IA accélère, le risque ne disparaît pas ; il se concentre davantage sur ceux qui doivent défendre ou signer le résultat. Elle recommande donc de rendre explicites hypothèses, zones d'incertitude, contrôles et responsabilités plutôt que de confondre vitesse de production et fiabilité.

La conséquence managériale est importante : le manager ne doit pas devenir le reviewer universel des agents.

Son rôle est plutôt de décider quel type de contrôle correspond à quel risque. Un contrôle peut prendre plusieurs formes :

• •test ou évaluation automatique avant exécution ;
• •approbation humaine préalable ;
• •double validation sur une opération sensible ;
• •contrôle a posteriori de 100 % des opérations pendant la phase d'apprentissage ;
• •échantillonnage lorsque le système devient suffisamment stable ;
• •seuil qui déclenche automatiquement une escalade ;
• •surveillance de dérive ou d'anomalies ;
• •possibilité d'interrompre immédiatement l'agent.

Le NIST recommande précisément de documenter les rôles de supervision humaine, les responsabilités organisationnelles, l'évaluation des sorties, les procédures d'incident et les mécanismes permettant de désactiver un système lorsque cela devient nécessaire.

La question managériale devient donc moins « qui relit ? » que : « quelle assurance avons-nous besoin d'obtenir avant de laisser cette action produire ses effets ? »

Les cinq niveaux d'autonomie qu'un manager peut réellement piloter

Plutôt qu'un choix binaire entre « humain » et « autonome », une équipe peut attribuer un niveau d'autonomie à chaque workflow.

Niveau 1 — L'agent informe

L'agent recherche, synthétise ou détecte. Il ne formule aucune décision opérationnelle. Exemple de contrôle : vérification ponctuelle de la qualité des sources et de la couverture.

Niveau 2 — L'agent propose

L'agent prépare une réponse, un diagnostic, un classement ou une action. Un humain décide systématiquement de l'exécuter ou non. C'est le modèle explicitement revendiqué par Lucca pour plusieurs usages RH : l'IA peut pré-analyser ou proposer, tandis que le recruteur ou le manager reste décisionnaire.

Niveau 3 — L'agent exécute après validation

Le système prépare l'ensemble du travail, mais une autorisation humaine reste nécessaire avant que l'action produise ses effets. Ce niveau convient notamment lorsque la production peut être automatisée mais que l'autorité ne doit pas l'être.

Niveau 4 — L'agent exécute seul dans un périmètre borné

L'agent peut agir sans validation préalable lorsque les conditions définies sont réunies. L'action doit alors être suffisamment observable et les limites suffisamment précises : type d'opération, périmètre, seuil, systèmes accessibles, critères d'escalade. Le contrôle humain se déplace de chaque opération vers le fonctionnement du système.

Niveau 5 — L'agent orchestre un workflow, l'humain intervient par exception

L'agent enchaîne plusieurs opérations et ne sollicite un humain qu'en cas d'incertitude, d'anomalie ou de dépassement d'un seuil. Roundtable offre un exemple parlant de cette logique : selon le témoignage recueilli par TPC, un processus portant sur environ 1 000 SPV fait remonter à l'humain seulement 15 à 20 cas problématiques. L'intérêt du cas réside moins dans le chiffre, issu d'un témoignage et non d'une validation indépendante, que dans la division du travail : la machine trie le volume, l'humain concentre son temps sur les exceptions.

Aucun de ces niveaux n'est « supérieur » aux autres. Le niveau pertinent dépend du risque du workflow.

Une entreprise peut parfaitement avoir un agent très autonome sur une opération interne banale et maintenir un mode « l'IA propose, l'humain tranche » sur une décision beaucoup plus sensible.

Ce que Klarna rappelle : davantage d'autonomie n'est pas toujours davantage de performance

L'histoire récente de Klarna fournit un contrepoint utile à une vision linéaire de l'automatisation.

L'entreprise avait communiqué de manière très agressive sur l'automatisation de son support et réduit ses effectifs dans un contexte combinant gel des embauches, attrition et montée de l'IA. Elle est ensuite revenue vers un modèle hybride, le CEO reconnaissant publiquement que la recherche du coût avait pris trop de poids et que la qualité s'était dégradée sur certains cas complexes ou à forte valeur. L'entreprise n'a pas abandonné l'automatisation : elle a réintroduit une capacité humaine sur les moments où elle jugeait cette présence nécessaire.

Ce cas ne démontre pas que les agents sont moins bons que les humains en support — les données publiées par Klarna faisaient également état d'améliorations sur certains indicateurs, et l'on ne peut pas attribuer simplement les évolutions d'effectifs ou de qualité à l'IA seule. Il montre autre chose :

optimiser un workflow pour son taux d'automatisation n'est pas équivalent à l'optimiser pour son résultat global.

Un manager devrait donc se méfier d'un KPI comme « 80 % des décisions sont prises sans humain ». Pris isolément, il ne dit presque rien. Il faut lui associer au minimum :

• •taux d'erreur ;
• •taux d'exception ;
• •rework ;
• •délai ;
• •satisfaction ou qualité ;
• •coût complet ;
• •gravité des erreurs ;
• •charge cognitive des humains recevant les exceptions.

Ce sont précisément les métriques que le modèle « humain sur les exceptions » juge nécessaires pour distinguer un gain réel d'un simple déplacement de charge.

Qui assume quand l'agent se trompe ?

C'est probablement la question la plus inconfortable, et la plus importante. Il faut d'abord distinguer deux notions.

La responsabilité opérationnelle répond à la question : dans notre organisation, qui doit s'assurer que ce workflow fonctionne et réagir lorsqu'il échoue ?

La responsabilité juridique dépend du contexte, de l'usage, des contrats et du droit applicable. Elle ne peut pas être ramenée à une règle générale selon laquelle « le manager est juridiquement responsable de tout ce que fait l'agent ».

Le règlement européen sur l'IA répartit par exemple des obligations entre différents acteurs de la chaîne de valeur et impose, pour certaines catégories à haut risque, des dispositifs de supervision humaine. Le texte insiste sur une IA pouvant être effectivement contrôlée et supervisée par des personnes ; ces obligations ne s'appliquent toutefois pas indistinctement à tout assistant ou agent utilisé dans une entreprise.

Pour le manager, la règle organisationnelle peut être plus simple :

Un agent peut recevoir de l'autonomie. Il ne doit pas devenir le propriétaire abstrait d'un résultat.

Chaque workflow agentique devrait avoir un owner humain identifiable. Cela ne signifie pas que cette personne doit vérifier chaque opération. Cela signifie qu'elle est responsable de concevoir ou de faire évoluer :

• •les objectifs ;
• •les limites d'action ;
• •les contrôles ;
• •les indicateurs ;
• •l'escalade ;
• •la réaction aux incidents ;
• •la boucle d'apprentissage.

L'un des pièges serait de conserver officiellement un humain responsable tout en lui retirant concrètement les moyens d'exercer cette responsabilité : pas de visibilité sur les actions, pas de logs, trop d'opérations à contrôler, impossibilité d'interrompre le système.

Une supervision purement nominale ne constitue pas une supervision.

Le manager hybride a quatre responsabilités nouvelles

Définir le territoire de décision

Le manager doit séparer ce qui peut être délégué, ce qui peut l'être sous conditions, et ce qui doit rester humain. Cette cartographie ne doit pas être définie une fois pour toutes : l'autonomie peut augmenter après observation des performances, ou diminuer après un incident.

Concevoir les frontières, pas seulement les instructions

Avec un collaborateur, une grande partie des contraintes reste implicite : expérience, culture commune, jugement. Un agent a besoin de limites beaucoup plus explicites. Il faut donc définir les systèmes accessibles, les données autorisées, les seuils financiers ou opérationnels pertinents, les critères d'escalade, les situations interdites et la manière d'interpréter l'incertitude.

Organiser l'assurance qualité

Plusieurs cas observés montrent un déplacement du travail vers la review et les évaluations. La fonction du manager n'est pas nécessairement d'effectuer lui-même ces contrôles, mais d'assurer qu'ils existent, qu'ils sont dimensionnés et que quelqu'un possède l'autorité nécessaire lorsque les critères ne sont pas remplis.

Transformer les erreurs en amélioration du système

Dans une organisation classique, une erreur peut donner lieu à un feedback individuel. Avec un agent, il faut également se demander : le contexte fourni était-il insuffisant ? Une règle manquait-elle ? L'évaluation aurait-elle dû détecter l'erreur ? Le seuil d'escalade était-il trop élevé ? Avons-nous accordé trop tôt ce niveau d'autonomie ? L'agent avait-il accès à une action qu'il n'aurait pas dû pouvoir effectuer ?

Le post-mortem ne porte donc plus seulement sur qui s'est trompé, mais sur pourquoi l'architecture de contrôle a laissé passer l'erreur.

Attention au deuxième effet : les humains récupèrent les décisions les plus difficiles

Une organisation très automatisée peut donner l'impression que le rôle humain devient plus intéressant : moins de tâches répétitives, davantage de jugement. C'est possible. Mais ce n'est pas automatique.

Le modèle « humain sur les exceptions » comporte un paradoxe : lorsque l'agent élimine progressivement les dossiers standards, la journée de l'humain peut devenir une succession presque exclusive de cas ambigus, émotionnels ou risqués.

Reléguer l'humain aux exceptions sans autorité ni boucle d'apprentissage est un anti-pattern reconnu. Pour le manager, cela introduit un nouveau problème de capacité.

Avant, dix personnes pouvaient traiter cent dossiers relativement homogènes. Demain, l'agent en traite peut-être quatre-vingt-dix. Mais les dix autres ne représentent pas nécessairement 10 % de l'effort. Ils peuvent concentrer la majorité du stress, du jugement et de la responsabilité.

Le dimensionnement des équipes ne peut donc plus reposer uniquement sur le volume résiduel. Il faut suivre également :

• •la complexité moyenne des exceptions ;
• •leur durée de traitement ;
• •leur concentration sur certaines personnes ;
• •les interruptions ;
• •le niveau émotionnel ou relationnel du travail ;
• •la possibilité pour les humains d'influencer les règles qui génèrent ces exceptions.

Le manager d'une équipe hybride gère ainsi deux capacités différentes : la capacité de production automatisée et la capacité humaine d'absorption de l'incertitude.

Ce que les données ne permettent pas encore d'affirmer

• •Qu'un ratio universel d'autonomie existe. Aucun corpus sérieux ne permet de dire qu'un agent devrait décider seul dans 60 %, 80 % ou 95 % des situations.
• •Que le manager deviendra principalement un « manager d'agents ». Certaines entreprises comme Lucca intègrent l'IA tout en conservant des structures d'équipes largement inchangées.
• •Que davantage d'autonomie réduit nécessairement les effectifs. Anthropic recrute malgré un usage extrêmement intensif d'agents ; Pennylane continue également à développer ses équipes.
• •Que toute vérification doit être humaine. Les systèmes les plus matures combinent contrôles automatisés, évaluations, premières reviews par agent et arbitrages humains.
• •Que la « responsabilité humaine » suffit en elle-même. Sans information, droit d'arrêt, temps disponible et autorité réelle, elle peut devenir une simple fiction organisationnelle.

La lecture DRYVE : le vrai sujet n'est pas l'autonomie de l'agent, mais l'architecture de l'autorité

L'erreur serait de traiter les agents comme de nouveaux collaborateurs auxquels on appliquerait simplement les méthodes de délégation existantes.

Un humain possède du jugement tacite, comprend généralement les conséquences sociales d'une action et peut être interrogé sur son intention. Un agent fonctionne autrement. Il faut donc remplacer une partie des règles implicites du management par une architecture d'autorité explicite.

À l'ère des agents, la qualité du management se mesurera moins au nombre de décisions conservées par le manager qu'à sa capacité à placer chaque décision au bon niveau : automatique lorsqu'elle est suffisamment bornée, déléguée lorsqu'elle peut l'être, escaladée lorsqu'elle devient incertaine et assumée par un humain lorsqu'elle engage réellement l'organisation.

Cela modifie aussi la notion d'autonomie humaine. Doctolib est intéressant précisément parce que la même logique qui permet de travailler avec des agents peut permettre de rendre davantage d'autorité aux collaborateurs : si une décision est réversible, pourquoi attendre systématiquement le manager ?

Le paradoxe est donc intéressant. L'organisation agentique pourrait produire davantage de centralisation, parce que chaque action semble devoir être contrôlée. Ou elle pourrait au contraire forcer l'entreprise à mieux expliciter ses droits de décision et permettre davantage de décentralisation.

L'outil ne tranche pas entre les deux. Le design managérial, oui.

Playbook : mettre un agent sous responsabilité en dix questions

Avant qu'un agent passe d'une expérimentation à un workflow réel, le manager responsable devrait être capable de répondre clairement aux questions suivantes.

• •Quel résultat lui confions-nous ? L'objectif est-il formulé en termes de résultat et non simplement de tâche ou de prompt ?
• •Quelles décisions l'agent peut-il prendre seul ? Les droits de décision sont-ils écrits plutôt qu'implicites ?
• •Quelle est la réversibilité de chaque action ? Combien de temps, d'argent et d'effort faut-il pour revenir en arrière ?
• •Quel est le périmètre maximal d'une erreur ? Une erreur touche-t-elle un brouillon, un dossier, cent clients ou tout un système ?
• •Qu'est-ce qui déclenche obligatoirement une escalade ? Incertitude, montant, anomalie, absence de données, nouveau cas, risque juridique ou autre seuil ?
• •Quel contrôle précède ou suit l'action ? Évaluation automatique, approbation humaine, double validation, contrôle a posteriori ou échantillonnage ?
• •Qui possède l'autorité finale ? Une personne ou une fonction clairement identifiable peut-elle suspendre, corriger ou modifier le workflow ?
• •Que gardons-nous comme preuve ? Pouvons-nous reconstituer ce que l'agent a vu, décidé, produit et exécuté ?
• •Comment apprenons-nous des erreurs ? Les exceptions et corrections changent-elles réellement les règles, les évaluations ou le contexte donné à l'agent ?
• •Mesurons-nous le résultat global ? Suivons-nous erreur, rework, délai, qualité, coût et charge humaine, et pas seulement le taux d'automatisation ?

Une fiche de délégation à utiliser pour chaque agent

La conviction

Le management hybride ne sera probablement pas un métier consistant à passer sa journée à observer des agents travailler.

Il sera davantage un métier de conception des responsabilités.

L'enjeu n'est pas de choisir une fois pour toutes entre « décision humaine » et « décision IA ». Il est de construire une organisation capable d'accorder progressivement de l'autonomie là où les risques sont maîtrisables, tout en maintenant une autorité humaine réelle lorsque l'incertitude, l'impact ou l'irréversibilité l'exigent.

Les meilleurs managers ne seront donc pas nécessairement ceux qui contrôlent le plus. Ce seront ceux qui savent répondre, pour chaque workflow, à trois questions simples :

Qui peut décider ? Qui doit vérifier ? Qui doit pouvoir dire stop, et assumer ce qui se passe ensuite ?