De producteur à superviseur : comment l'IA redécoupe les métiers quand elle absorbe le travail standard

Quand l'IA prend en charge le premier jet d'un code, la réponse simple d'un ticket support, le contrôle de centaines de dossiers ou le rapprochement entre une offre et des CV, une formule revient systématiquement : l'humain devient superviseur.

Elle décrit une partie du mouvement réel. Mais elle est trop simple pour guider une organisation. Car « superviser » peut recouvrir des réalités très différentes : vérifier un résultat, orchestrer plusieurs agents, résoudre les cas que la machine n'a pas su traiter, définir les critères en amont, ou conserver la décision finale. Ces activités n'exigent ni les mêmes compétences, ni la même organisation, ni les mêmes indicateurs.

Le véritable changement est ailleurs : l'IA ne modifie pas seulement la quantité de travail humain. Elle redécoupe le métier entre production, contrôle, exception et décision. Et cette recomposition peut aussi créer de nouveaux problèmes : surcharge de review, concentration des cas difficiles, perte d'apprentissage ou responsabilité accrue sans moyens supplémentaires.

En bref

• •Le déplacement du travail vers la supervision, la review et le traitement des exceptions est l'un des enseignements les plus documentés parmi les cas observés — même si le panel reste non représentatif du marché.
• •Le signal est particulièrement net dans l'engineering : quand davantage de code est généré, la capacité à spécifier, tester, reviewer et intégrer peut devenir plus déterminante que la capacité à produire une première version.
• •Dans le support et les opérations, un autre modèle apparaît : l'IA traite ou filtre les cas standards, l'humain se concentre sur une fraction plus complexe du flux. Mais Klarna rappelle qu'un taux d'automatisation maximal n'est pas nécessairement l'optimum organisationnel.
• •Dans le recrutement, le cas Lucca dessine une évolution plus prudente : l'IA automatise une partie du tri, mais le rôle et les droits de décision du recruteur restent explicitement préservés. Automatiser une tâche ne conduit donc pas nécessairement à reconstruire le métier autour de la supervision.

Le métier ne bascule pas vers un unique rôle de superviseur

Un métier peut être décomposé, très schématiquement, en cinq catégories d'activités : cadrer ce qu'il faut faire → produire → vérifier → traiter les exceptions → décider et assumer.

Historiquement, beaucoup de métiers de bureau consacraient une part importante de leur temps à la deuxième étape : produire. Écrire le code. Répondre au ticket. Contrôler le dossier. Lire les candidatures. Préparer l'analyse.

L'IA attaque en priorité cette zone lorsqu'elle est suffisamment répétitive et formalisable. Dans certains workflows, elle commence également à prendre en charge un premier niveau de vérification. Le travail humain ne disparaît donc pas nécessairement : son centre de gravité se déplace.

Cette lecture rejoint le modèle « humain sur les exceptions » identifié dans plusieurs cas observés, avec une condition souvent oubliée : sans mesure du volume automatisé, des exceptions, des erreurs et du rework, il est impossible de savoir si l'on a réellement amélioré le travail ou simplement déplacé la charge.

Une analyse du secteur du conseil décrit un déplacement comparable : moins produire et assembler, davantage contextualiser, orchestrer et décider. Cette analogie est utile pour penser les métiers de startups et scale-ups, mais elle reste une transposition : une mission de conseil, un workflow de support et une chaîne de production logicielle n'ont évidemment ni les mêmes risques ni les mêmes contraintes.

Engineering : quand produire du code devient plus facile, vérifier ce qu'il faut construire devient plus important

C'est dans l'engineering que le passage du producteur au superviseur est aujourd'hui le mieux documenté.

Ce qui est documenté

Chez Anthropic, le CPO Mike Krieger a indiqué que 90 à 95 % du code de Claude Code serait produit par Claude Code lui-même. Les ingénieurs passent alors davantage de temps à piloter, reviewer et intégrer. Le même cas fait apparaître un autre changement : lorsque le volume de pull requests augmente, la merge queue et la capacité de décision deviennent de nouveaux goulots. Ce cas reste toutefois classé en confiance moyenne : Anthropic est un laboratoire AI-native, non comparable directement à une scale-up classique.

Doctolib fournit un signal d'une autre nature. Après une phase pilote en 2025, l'entreprise a basculé ses 600 ingénieurs vers un mode décrit comme « agentic-first » début 2026. Le changement documenté ne concerne pas uniquement les outils : le cadre de décision distingue les décisions réversibles, que les builders peuvent prendre sans attendre un arbitrage produit, des décisions irréversibles qui restent sous contrôle du PM.

Ces exemples convergent vers une idée : si produire devient moins coûteux, savoir donner une bonne direction à cette production prend davantage de valeur.

Mais il existe une taxe cachée. Le programme de recherche de Google Cloud sur le développement logiciel parle en 2026 d'une véritable verification tax. Son analyse qualitative de 1 110 réponses d'ingénieurs Google montre que le temps économisé dans l'écriture est fréquemment réinvesti dans l'audit et la vérification. Davantage d'adoption de l'IA est associée à davantage de débit de livraison, mais aussi à davantage d'instabilité.

Accélérer le producteur sans redimensionner le système de contrôle peut simplement déplacer le bouchon.

Un ingénieur capable de générer trois fois plus de changements n'améliore pas nécessairement le système si un autre ingénieur doit ensuite consacrer trois fois plus d'attention à vérifier ce qui a été produit.

Ce que cela ne prouve pas

Ces cas ne démontrent pas que le développeur cessera d'écrire du code, ni que chaque équipe doit faire de ses ingénieurs des « managers d'agents ». Les situations les plus spectaculaires concernent des organisations à forte maturité technique. L'IA y est décrite comme un amplificateur : une équipe disposant de tests robustes, de bons outils internes et de workflows clairs peut en tirer davantage de valeur ; une organisation fragile risque surtout d'accélérer sa production de dette.

Lecture DRYVE

Le métier d'ingénieur ne se déplace donc pas simplement du code vers la review. Il se déplace vers un ensemble plus large : comprendre le problème, spécifier suffisamment bien, choisir ce qui peut être délégué, construire les critères de validation, examiner les cas limites et assumer l'intégration en production.

L'enjeu managérial n'est plus seulement « combien de code notre équipe peut-elle produire ? ». Il devient : « quelle quantité de production pouvons-nous raisonnablement spécifier, contrôler et absorber ? »

Support : l'humain sur les exceptions est crédible, mais ce n'est pas automatiquement un meilleur métier

Le support offre probablement l'image la plus intuitive du nouveau partage du travail. La machine répond aux questions simples, l'humain prend les situations particulières. Sur le papier, le modèle paraît évident. Sur le terrain, il est plus ambivalent.

Ce qui est documenté

Chez Alan, 40 % des demandes membres seraient résolues par l'IA, et jusqu'à 70 % des demandes simples, selon un témoignage recueilli directement. L'équipe de relations membres, d'environ 100 personnes, serait restée stable alors que le nombre de membres progressait de 34 %. Le rôle d'« Agent Care » y est décrit comme évoluant vers davantage de validation et de supervision des réponses générées. Il s'agit là encore d'un témoignage d'entreprise, non d'une mesure indépendante du ROI.

Un travail académique plus ancien offre un contrepoint intéressant. Dans une étude portant sur 5 179 agents de support, Erik Brynjolfsson, Danielle Li et Lindsey Raymond ont observé un gain de productivité proche de 14 % avec une assistance générative, les gains étant particulièrement élevés chez les agents moins expérimentés. Mais les humains continuaient ici à réaliser le travail : l'IA les assistait davantage qu'elle ne les remplaçait par un workflow d'exception.

Deux trajectoires sont donc possibles : une IA qui augmente l'agent dans le traitement du flux, ou une IA qui prend le flux standard et ne fait remonter que les exceptions.

Le cas Klarna invite justement à ne pas confondre les deux. Après avoir très fortement automatisé son service client et communiqué sur l'équivalent de centaines d'agents pris en charge par son assistant, l'entreprise a réintroduit une capacité humaine plus explicite sur les situations complexes. Le CEO a reconnu que la recherche de réduction des coûts avait pris trop de poids par rapport à la qualité. L'IA n'a pas été abandonnée : le modèle a été recalibré vers une articulation plus hybride, avec le maintien d'humains pour certains cas sensibles comme l'usurpation d'identité.

Ce que cela ne prouve pas

Klarna ne prouve pas que « l'IA dans le support ne fonctionne pas ». Alan ne prouve pas davantage qu'un support peut augmenter indéfiniment son volume avec le même effectif. Et l'étude portant sur les 5 179 agents ne prouve pas qu'un assistant produira partout 14 % de productivité : elle concerne une entreprise, une technologie et un environnement précis. Les trois cas montrent surtout que la frontière entre machine et humain est une variable à concevoir, pas une vérité technologique.

Lecture DRYVE

Le danger du modèle « humain sur les exceptions » tient dans son nom même. Si l'IA retire progressivement toutes les demandes faciles, le travail humain restant n'est plus un échantillon représentatif du support. Il devient un flux concentré de frustrations, d'ambiguïtés, de conflits, de cas sensibles et de problèmes que le système n'a pas réussi à résoudre. Le nombre de dossiers baisse, mais leur intensité cognitive et émotionnelle moyenne peut monter.

La question People ne peut donc pas être seulement « quel taux de tickets pouvons-nous automatiser ? ». Elle doit aussi devenir : « quel travail sommes-nous en train de fabriquer pour les personnes qui restent dans la boucle ? »

Ops : le changement le plus profond n'est parfois pas d'automatiser le traitement, mais d'automatiser la recherche des problèmes

Le cas Roundtable est particulièrement éclairant parce qu'il montre une distinction importante entre traiter et trier.

Ce qui est documenté

Roundtable gère notamment des SPV d'investissement dans plusieurs pays européens. Selon un témoignage recueilli par TPC, un processus auparavant vérifié dossier par dossier a été automatisé avec Claude Code : sur environ 1 000 SPV contrôlés, seuls 15 à 20 cas problématiques remonteraient désormais vers l'humain — un passage des ops du traitement de masse à la gestion des 1 à 2 % d'exceptions.

Fleet offre un deuxième signal. D'après un témoignage recueilli par TPC, l'entreprise aurait multiplié son chiffre d'affaires par trois depuis 2023 tout en maintenant constants ses effectifs de supply et de support ; deux personnes continueraient notamment à tenir la fonction supply grâce à l'automatisation d'une part croissante du travail. Là encore, les chiffres proviennent d'un témoignage d'entreprise et ne constituent pas une étude indépendante.

Ce que cela prouve réellement

Ces deux cas montrent qu'un workflow opérationnel suffisamment répétitif peut être restructuré autour d'un principe puissant : la machine examine le volume, l'humain examine les anomalies.

Ce principe peut modifier beaucoup plus profondément le métier qu'un simple copilote. L'opérateur n'exécute plus cent fois le même contrôle : il doit comprendre pourquoi certains dossiers sortent de la norme, déterminer si l'anomalie est réelle, décider de l'action et éventuellement améliorer la règle qui permettra de traiter automatiquement un cas similaire demain. Le travail se rapproche alors du diagnostic.

Ce que cela ne prouve pas

Ni Roundtable ni Fleet ne démontrent que le modèle est généralisable à n'importe quelle fonction Ops. Ce sont des structures relativement compactes, avec une culture technique forte et des dirigeants directement impliqués dans la construction des automatisations. Roundtable ne démontre pas non plus que le contrôle automatique atteint sans supervision la même qualité qu'un contrôle humain — une limite explicitement mentionnée.

Lecture DRYVE

Le piège consiste à traiter le taux d'exception comme une simple métrique d'efficacité. Il doit devenir une métrique d'organisation. Si 2 % du volume mobilisent désormais l'ensemble du travail humain, il faut savoir qui possède ces 2 %, combien de temps ils prennent, quels risques ils concentrent, quels profils savent les résoudre, et comment les apprentissages retournent dans le système.

Sans cette boucle, l'humain devient simplement la poubelle des cas que l'automatisation n'a pas compris.

Recrutement : automatiser le tri ne veut pas dire déléguer le jugement

Le recrutement montre une autre variante de la transformation. Ici, le cas le plus instructif est peut-être celui où l'organisation refuse précisément de transformer le recruteur en simple superviseur d'algorithme.

Ce qui est documenté

Lucca utilise l'IA pour rapprocher les critères d'une offre d'emploi et les informations présentes dans un CV. Mais l'entreprise indique explicitement que le recruteur reste décisionnaire à chaque étape et peut ignorer les critères ou recommandations issus de l'analyse. Son propre guide consacré au CV matching rappelle plusieurs limites : la qualité dépend fortement des critères d'entrée, les CV atypiques peuvent être défavorisés et les écarts entre classement automatique et décisions humaines doivent être suivis pour comprendre les erreurs du système.

Lucca fait justement partie des contre-exemples aux transformations structurelles : les équipes restent organisées de manière comparable et l'IA vient s'insérer dans leurs workflows plutôt que provoquer une refonte visible des rôles.

Ce que cela ne prouve pas

Aucune donnée ne permet d'affirmer que Lucca réduit ses besoins de recruteurs grâce à cette automatisation, ni de mesurer précisément l'impact sur le temps de recrutement ou la qualité des embauches. Le cas montre un choix de partage des responsabilités, pas un ROI organisationnel.

Lecture DRYVE

Lorsque le tri devient plus facile, la qualité du recrutement dépend encore davantage de ce qui se passe avant et après le tri. Avant : définir ce que l'on cherche réellement. Après : comprendre un parcours, tester une capacité, conduire un entretien, confronter les avis et prendre une décision.

L'IA peut donc réduire le temps consacré à lire des CV tout en augmentant la valeur d'une compétence beaucoup moins automatisable : la capacité à formuler de bons critères et à reconnaître quand un candidat intéressant ne rentre précisément pas dans ces critères.

Ici, « superviser l'IA » serait presque une mauvaise description du métier. Le recruteur reste d'abord responsable d'une décision humaine, avec une machine qui l'aide à préparer cette décision.

Trois idées reçues que le corpus contredit

Tous les métiers ne deviennent pas des métiers de supervision

Le déplacement du travail vers la supervision est documenté dans plusieurs entreprises. Mais l'inverse l'est tout autant : l'IA peut être intégrée sans restructuration significative du rôle. Lucca conserve des équipes de six à huit personnes organisées comme auparavant. Pennylane automatise une partie du travail comptable tout en continuant à renforcer ses équipes et en faisant intervenir des experts-comptables dans la conception du produit. Joko développe des usages IA tout en poursuivant sa croissance d'effectifs.

L'idée « l'IA transforme nécessairement les producteurs en superviseurs » serait donc trop forte. Une formulation plus défendable : lorsque l'IA prend effectivement en charge une part significative d'un workflow standard, le travail humain tend à se concentrer sur la spécification, la review, l'orchestration, les exceptions et la décision — mais le degré de recomposition dépend du métier, du niveau réel d'automatisation et des choix d'organisation.

Superviser n'est pas nécessairement un travail de plus grande valeur

L'idée selon laquelle l'IA enlèverait mécaniquement les tâches ingrates pour laisser aux humains des activités plus intéressantes est séduisante. Elle n'est pas démontrée.

Dans l'engineering, la production plus rapide peut créer une surcharge de vérification, avec des risques identifiés sur l'apprentissage lorsque l'IA permet de contourner trop tôt l'effort nécessaire pour acquérir une expertise profonde. Dans le support, l'humain peut hériter presque exclusivement des clients insatisfaits ou des situations impossibles à standardiser. Dans les Ops, il peut perdre le contact quotidien avec les cas simples qui lui permettaient auparavant de comprendre intuitivement le fonctionnement du système. Dans le recrutement, il peut finir par considérer la présélection de l'algorithme comme une réalité objective alors qu'elle reflète d'abord les critères qui lui ont été fournis.

Le déplacement vers la supervision augmente parfois la valeur du rôle. Il peut aussi augmenter sa charge cognitive, sa responsabilité ou sa monotonie d'une autre manière.

C'est un choix de design organisationnel, pas une conséquence automatique de la technologie.

Moins de production humaine ne signifie pas mécaniquement moins d'humains

C'est une extrapolation particulièrement tentante. Elle n'est pas soutenue par les cas observés : Anthropic continue de recruter malgré une production de code très agentique, Lucca a poursuivi ses embauches, Pennylane augmente fortement ses effectifs, bsport indique vouloir continuer à recruter des juniors malgré l'automatisation d'une partie du développement et du support.

La productivité peut être utilisée pour réduire des effectifs. Elle peut aussi être utilisée pour absorber plus de volume, améliorer la qualité, raccourcir les délais, ouvrir de nouveaux produits ou déplacer les personnes vers d'autres activités.

Les données disponibles permettent donc de parler d'un redécoupage du travail avec davantage de confiance que d'une réduction générale du travail humain.

Il n'existe pas un métier de superviseur, mais quatre

La notion de supervision devient réellement utile lorsqu'on la décompose.

Cette distinction a une conséquence importante pour les managers et les équipes People.

On ne peut pas simplement supprimer 30 % des tâches d'un métier et considérer que le nouveau rôle apparaîtra naturellement.

Un reviewer doit disposer du temps nécessaire pour reviewer. Un spécialiste des exceptions doit être formé aux cas difficiles. Un orchestrateur doit avoir les droits de décision permettant réellement d'arbitrer. Un recruteur responsable de la décision ne doit pas être évalué uniquement sur le nombre de candidatures traitées.

Le redesign du métier commence précisément ici : quand on redéfinit les responsabilités, les compétences et les indicateurs autour du nouveau travail restant.

Ce que cela change pour les managers

Le premier changement consiste à ne plus confondre production et contribution. Une personne qui écrit moins de réponses, de code ou de dossiers peut être plus déterminante qu'auparavant si elle est devenue le point de contrôle de centaines d'outputs générés automatiquement.

Le deuxième consiste à gérer explicitement la capacité de review. Dans beaucoup d'organisations, cette activité était autrefois secondaire : chacun vérifiait essentiellement le travail produit par une quantité limitée de collègues. Avec l'IA, la capacité de production peut augmenter beaucoup plus vite que la capacité humaine d'attention.

Le troisième concerne les droits de décision. Le cadre documenté chez Doctolib est intéressant précisément parce qu'il ne se limite pas à « utiliser des agents » : il tente de formaliser quelles décisions peuvent être prises localement et lesquelles exigent encore un arbitrage.

Enfin, le manager doit protéger l'apprentissage. Le risque est particulièrement important pour les collaborateurs moins expérimentés. Si toutes les tâches standards disparaissent trop vite, on peut supprimer en même temps une partie des répétitions qui permettaient de construire des réflexes métier. Il est recommandé de préserver des situations d'apprentissage profond et d'organiser la review des décisions générées avec des profils expérimentés — un sujet qui dépasse largement l'engineering.

Une organisation peut devenir plus efficace aujourd'hui tout en affaiblissant le mécanisme qui fabrique ses experts de demain.

Redécouper un métier avant de l'automatiser davantage

Avant de viser un nouveau taux d'automatisation, cette checklist permet de vérifier si le rôle humain qui restera derrière a réellement été conçu.

• •Décomposer le métier en tâches plutôt qu'en intitulé de poste. Qu'est-ce qui relève du cadrage, de la production, du contrôle, de l'exception et de la décision ?
• •Identifier précisément le travail standard. Quel volume est réellement répétitif, formalisable et suffisamment prévisible pour être confié à l'IA ?
• •Mesurer l'avant. Volume, temps de traitement, qualité, erreurs, rework et satisfaction doivent être connus avant de conclure à un gain.
• •Définir le taux d'exception acceptable. Que doit-il se passer lorsqu'un agent n'est pas suffisamment sûr, rencontre un cas inédit ou produit une réponse incohérente ?
• •Nommer le propriétaire de la décision. Qui peut approuver, rejeter, corriger ou interrompre une action de l'IA ? Qui reste responsable du résultat ?
• •Dimensionner la review. La quantité d'outputs générés est-elle compatible avec la capacité humaine de vérification, ou sommes-nous en train de créer un nouveau goulot ?
• •Analyser la qualité du travail restant. L'humain récupère-t-il des tâches réellement plus intéressantes ou uniquement les problèmes les plus pénibles et les plus risqués ?
• •Revoir les indicateurs individuels. Mesure-t-on encore le nombre de tickets, de dossiers ou de lignes produites alors que le rôle s'est déplacé vers la qualité, les exceptions et la décision ?
• •Protéger l'apprentissage. Quelles situations permettront encore aux juniors et aux nouveaux arrivants de construire une expertise lorsque les cas simples sont automatisés ?
• •Créer une boucle de retour. Les exceptions corrigées par les humains améliorent-elles effectivement les règles, les prompts, les données, les évaluations ou le workflow suivant ?

Une organisation qui ne sait pas répondre à ces questions n'a probablement pas encore redesigné le rôle. Elle a surtout automatisé une partie de son ancien workflow.

La conviction

Le passage de producteur à superviseur est un signal réel. Mais pris au pied de la lettre, il masque la partie la plus importante de la transformation.

Ce que l'IA automatise est relativement facile à identifier. Ce qu'elle laisse aux humains demande beaucoup plus de travail de conception.

Dans l'engineering, ce travail restant peut être la spécification, la review et l'architecture. Dans le support, ce sont souvent les situations sensibles et ambiguës. Dans les Ops, le diagnostic et les anomalies. Dans le recrutement, la définition des critères et le jugement.

Le problème n'est donc pas seulement de savoir jusqu'où automatiser. Il est de décider quel métier humain on construit autour de l'automatisation.

Une bonne transformation ne se mesure pas au fait que l'humain ne touche plus que 5 % du flux. Elle se mesure aussi à la qualité de ces 5 %, à sa charge, à la clarté des responsabilités, à la capacité d'apprentissage et à la possibilité pour les personnes de réellement exercer leur jugement.

L'IA peut absorber le travail standard. L'organisation, elle, doit encore concevoir le travail qui reste.