Développeur, chef de projet, recruteur, Business Manager : quatre métiers à réinventer maintenant

L'IA ne transforme pas tous les métiers de la même manière. Pour le développeur, le déplacement vers la génération, la review et l'orchestration est déjà documenté. Pour le recruteur, l'automatisation touche clairement le sourcing et la présélection, sans supprimer la responsabilité humaine. Pour le chef de projet et le Business Manager, la mutation est moins mesurée : elle se déduit surtout de la transformation du delivery et du modèle économique des entreprises de services.

C'est précisément pour cela qu'il faut éviter le catalogue de « métiers du futur ». Le sujet n'est pas de rebaptiser quatre fonctions. Il est de comprendre quelle partie de leur valeur devient moins rare, quelle nouvelle responsabilité apparaît et comment on continue à former des professionnels compétents lorsque l'IA prend une partie du travail qui servait autrefois à apprendre.

En bref

• •Le développeur se déplace progressivement de la seule production de code vers la spécification, l'orchestration, la review et la responsabilité du comportement produit.
• •Le chef de projet perd une partie de sa valeur de coordination administrative lorsque reporting, comptes rendus et suivi deviennent automatisables. Sa valeur remonte vers l'arbitrage, la qualité du système de delivery et la gestion des décisions.
• •Le recruteur peut déléguer davantage de recherche, de matching et de préparation, mais devient d'autant plus responsable de la qualité de l'évaluation, des biais, de la compréhension du potentiel et de l'expérience candidat.
• •Le Business Manager est probablement celui dont la transformation est la moins documentée et pourtant l'une des plus structurantes pour les ESN : lorsque la production nécessite moins de jours, vendre principalement des profils et des TJM devient insuffisant. Il doit apprendre à vendre une capacité, une preuve, un actif ou un résultat.
• •Dans les quatre cas, la même bascule apparaît : moins de valeur dans l'exécution standard, davantage dans le contexte, le jugement, la vérification et la responsabilité. Mais ce mouvement n'est ni uniforme ni irréversible.

Réinventer un métier ne signifie pas supprimer son intitulé

Sur un corpus de trente entreprises sélectionnées pour leurs signaux organisationnels, 35 rôles transformés ou renommés et 29 rôles créés ont été recensés dans le contexte du virage IA : l'ingénieur devenu orchestrateur d'agents, le tech lead devenu orchestrateur, les ops recentrés sur les exceptions ou encore le recruteur augmenté. Mais l'échantillon n'est pas représentatif du marché et les intitulés varient fortement d'une entreprise à l'autre.

Le contre-exemple est instructif. Chez Lucca, les équipes de six à huit personnes restent structurées de manière proche de l'organisation antérieure : l'IA est ajoutée au travail sans refonte fondamentale de l'organisation. Chez Pennylane, l'IA n'empêche ni la croissance des effectifs ni le renforcement des compétences métier.

Autrement dit, la transformation d'un métier peut précéder la transformation de l'organigramme, et parfois ne jamais produire de nouvel intitulé.

C'est aussi ce que suggère la conjoncture des ESN françaises. En juillet 2026, Numeum et Xerfi évaluent le marché français des ESN à 34,6 milliards d'euros, en légère croissance de 1 %. 58 % des ESN interrogées déclarent se repositionner via l'automatisation et l'IA. Les gains de productivité liés à l'IA sont estimés dans l'étude à 15 % en 2025 et 22,3 % en 2027, mais Numeum souligne qu'ils restent difficiles à convertir en marge.

C'est dans cet écart, entre productivité technique et création de valeur organisationnelle, que se joue la réinvention des quatre métiers.

Développeur : du code produit au comportement garanti

C'est le métier pour lequel les signaux sont aujourd'hui les plus solides.

Anthropic, Doctolib, Stripe, Dust, Fleet ou bsport montrent sous des formes différentes un déplacement du travail vers la supervision et la review. Chez Doctolib, les 600 ingénieurs sont passés en mode agentic-first en janvier 2026 après une année de pilotes. Certains orchestrent plusieurs agents en parallèle. Chez Dust, l'entreprise déclarait début 2026 qu'environ 70 % du code était écrit par des agents, avec d'importantes variations entre ingénieurs. Chez Fleet, le dirigeant décrit les développeurs comme des « managers d'une IA ».

Gartner formule la même direction comme prévision, et non comme fait acquis : l'organisme estime que 90 % des ingénieurs logiciels en entreprise utiliseront des assistants de code en 2028 et anticipe un déplacement de l'implémentation vers l'orchestration, la résolution de problèmes et la conception de systèmes.

Mais le raccourci « IA = développeur plus productif » reste dangereux. DORA conclut dans son rapport 2025 que l'IA agit avant tout comme un amplificateur du système existant : elle renforce les qualités d'une organisation bien structurée mais peut aussi amplifier ses dysfonctionnements.

METR fournit un contre-exemple encore plus net. Dans une expérimentation randomisée menée début 2025 auprès de 16 développeurs open source expérimentés réalisant 246 tâches sur des dépôts qu'ils connaissaient bien, les développeurs disposant des outils IA ont mis 19 % de temps supplémentaire. METR précise explicitement que ce résultat ne permet pas de conclure que l'IA ralentit la majorité des développeurs. En février 2026, l'organisation estimait d'ailleurs probable que les outils plus récents apportent davantage de gains, tout en considérant ses nouvelles données comme trop biaisées pour quantifier proprement cette progression.

Ce que cela prouve : une part croissante de la production de code peut être déléguée dans certains environnements matures.

Ce que cela ne prouve pas : que produire davantage de code équivaut à produire davantage de valeur, ni que tous les développeurs gagnent le même temps.

Les compétences qui prennent de la valeur

Le bon développeur augmenté n'est pas simplement celui qui maîtrise le dernier outil de génération. Il doit devenir meilleur sur ce que l'IA ne peut pas deviner seule : architecture, connaissance du domaine, exigences non fonctionnelles, sécurité, observabilité, tests, arbitrage et compréhension du système complet.

Ce déplacement se formule comme un passage du producteur au superviseur. Dans plusieurs cas, le nouveau goulot devient la qualité des spécifications, des évaluations et de la review — un phénomène particulièrement documenté dans des organisations à forte culture d'ingénierie, qui ne peut pas être généralisé tel quel.

Les indicateurs à faire évoluer

Un développeur ne devrait pas être évalué sur le volume de code généré, ni sur le nombre d'agents qu'il sait faire travailler en parallèle.

Les indicateurs utiles se déplacent vers le lead time jusqu'à la mise en production, les défauts échappés en production, le taux de rework, le temps de review, la qualité et la couverture des tests et évaluations, le change failure rate, la capacité à expliquer les choix d'architecture, et le coût complet de production et d'exploitation.

Un parcours possible

0 à 3 mois : apprendre à utiliser l'IA sans perdre la compréhension du code produit ; vérifier chaque changement important.

3 à 6 mois : rédiger de meilleures spécifications, critères d'acceptation et tests avant de déléguer.

6 à 12 mois : devenir propriétaire d'un flux complet, de la demande au déploiement et à l'observabilité, plutôt que simple producteur de code.

Au-delà : se spécialiser dans l'architecture, la fiabilité, la sécurité, le métier, la plateforme ou l'orchestration de systèmes hybrides.

La séniorité ne pourra plus être assimilée au nombre de lignes que l'on sait produire sans aide, mais elle ne pourra pas davantage être réduite à la capacité de déléguer aveuglément à une machine.

Chef de projet : de coordinateur du travail à architecte du système de delivery

Pour le chef de projet, la prudence méthodologique est plus importante : nous disposons de beaucoup moins de données établissant l'apparition d'un « nouveau métier » que pour le développeur.

La transformation est surtout déductive.

Une partie importante du travail de coordination peut déjà être automatisée ou fortement assistée : synthèse des réunions, préparation des comptes rendus, consolidation de statuts, mise à jour de documents, détection des dépendances, préparation de certains plans d'action, recherche d'informations dans les projets.

Le déplacement général du conseil de la production vers l'orchestration s'accompagne d'un point particulier : avec l'agentique, des premières versions de livrables peuvent arriver d'un seul bloc, ce qui change le moment où le sens critique doit s'exercer — d'où la nécessité de former particulièrement les chefs de projet qui encadrent les jeunes professionnels utilisant l'IA.

Doctolib fournit une autre pièce du puzzle : l'entreprise a explicité les décisions que le PM doit conserver et celles que les product builders peuvent prendre lorsque la décision est facilement réversible. Ce n'est pas un modèle de gestion de projet généralisable, mais il montre que l'automatisation oblige à formaliser davantage les droits de décision.

Le chef de projet ne disparaît pas lorsque la coordination devient automatisable ; il perd surtout de la valeur lorsqu'il se limite à être la couche humaine qui transporte l'information entre les autres.

Si un agent sait collecter les statuts, signaler un retard et rédiger le compte rendu, le rôle humain doit remonter vers les questions auxquelles le système ne répond pas seul : pourquoi le projet bloque-t-il réellement ? Quelle dépendance faut-il éliminer plutôt que suivre ? Quelle décision attend inutilement trois validations ? Quelle promesse commerciale est incompatible avec la réalité du delivery ? Quel risque doit être porté au niveau exécutif ? Quelle sortie générée par un agent ne doit surtout pas être mise en production ?

Le terme « Agentic Delivery Manager » est parfois utilisé pour décrire cette évolution. Il faut bien le lire comme un modèle prospectif, pas comme un métier déjà établi sur le marché.

Les nouvelles compétences

Le chef de projet augmenté doit comprendre suffisamment l'IA pour savoir où elle peut agir, mais son avantage ne résidera probablement pas dans le prompting.

Il doit surtout progresser en décomposition d'un processus en tâches, décisions et exceptions ; définition de critères d'acceptation ; clarification des responsabilités ; mesure d'une baseline et d'un résultat ; gestion des risques liés aux agents ; conduite du changement ; capacité à challenger le delivery technique ; facilitation d'arbitrages difficiles.

Les nouveaux indicateurs

Le nombre de cérémonies tenues ou la fraîcheur du reporting devraient peser moins que le time-to-first-value, le délai entre apparition d'un problème et décision, l'âge des blocages, le nombre de handoffs inutiles, le taux de rework, le taux d'exception, la stabilité du delivery et l'adoption réelle de ce qui a été livré.

Un parcours possible

0 à 3 mois : automatiser son propre travail administratif tout en documentant ce qui mérite encore une intervention humaine.

3 à 6 mois : cartographier un processus complet en distinguant production, décision, vérification et responsabilité.

6 à 12 mois : piloter un projet où les droits de décision des humains et des agents sont explicites et où le succès est mesuré autrement que par le respect du planning.

La transformation importante n'est donc peut-être pas « chef de projet → manager d'agents ». Elle est plus exigeante : chef de projet → responsable de la qualité du système qui fait travailler ensemble humains, technologie et organisation.

Recruteur : du matching au jugement sur le potentiel

Le recrutement est un cas intéressant parce que la frontière entre ce qui s'automatise et ce qui doit rester humain est plus visible.

Chez Fleet, un agent peut analyser environ 200 profils LinkedIn contre une scorecard avant qu'un humain n'intervienne. Chez Lucca, l'IA rapproche les critères d'une offre des éléments du CV, tandis que le recruteur reste décisionnaire à chaque étape.

Lucca décrit aujourd'hui publiquement son approche de la même manière : le CV matching sert à accélérer le tri, mais l'entreprise recommande de compléter systématiquement la sélection par un échange humain et insiste sur la qualité des critères utilisés.

Ces cas n'établissent pas que tous les recruteurs doivent fonctionner ainsi. Ils montrent cependant qu'une partie du travail qui justifiait autrefois beaucoup de temps, trouver, comparer, résumer, classer, peut être fortement comprimée.

Le paradoxe est alors évident. Plus le matching devient facile, moins le matching peut constituer la valeur différenciante du recruteur.

Or le métier ne se réduit pas à comparer deux listes de mots-clés. Il faut encore comprendre pourquoi une expérience apparemment éloignée pourrait devenir pertinente, détecter un potentiel, tester une motivation, comprendre le contexte d'un départ, apprécier la capacité à apprendre, convaincre un candidat et aider un manager à clarifier ce qu'il cherche réellement.

L'IA peut même rendre cette dimension plus importante : si tout le monde dispose d'outils similaires pour identifier les mêmes profils, le véritable avantage se déplace vers la capacité à évaluer ce que le CV ne montre pas.

La compétence la plus importante pourrait devenir la définition du besoin

Une IA de matching ne corrige pas une mauvaise scorecard. Elle l'exécute plus vite.

C'est probablement l'un des enseignements les plus transposables : lorsque la production devient très rapide, la qualité de l'entrée devient plus importante.

Le recruteur doit donc être capable de challenger une demande du type « je veux cinq ans d'expérience sur telle technologie », distinguer une compétence indispensable d'une compétence apprenable et comprendre le rôle réel attendu derrière un intitulé.

Il devient moins un opérateur de recherche qu'un concepteur du dispositif d'évaluation.

Que mesurer ?

Le time-to-hire demeure utile, mais devient dangereux s'il prend le dessus sur la qualité de recrutement quelques mois après l'arrivée, le temps nécessaire pour atteindre l'autonomie, la rétention, la mobilité interne, la qualité de l'expérience candidat, la performance des méthodes d'assessment et la diversité des parcours finalement recrutés.

Un nouveau type d'entretien

Une conséquence raisonnable de l'évolution des métiers consiste à tester davantage la collaboration avec l'IA elle-même.

Pour un métier qui utilisera des agents quotidiennement, une mise en situation pourrait demander au candidat de travailler avec une IA sur un problème réel, puis d'expliquer ce qu'il a délégué, ce qu'il a contrôlé, quelles erreurs il a détectées, ce qu'il a refusé de suivre et quelle décision il assume finalement.

Ce format reste une proposition, pas une pratique devenue standard. Son intérêt est de déplacer l'évaluation de la maîtrise d'un outil vers le jugement dans un environnement augmenté.

Business Manager : du placement de ressources à l'architecture de valeur

C'est probablement la fiche la plus importante pour les ESN, et celle pour laquelle il faut le plus clairement distinguer les faits de la déduction.

Nous ne disposons pas d'une étude démontrant que le métier de Business Manager est déjà en train de devenir un « architecte de valeur ». En revanche, les conditions économiques qui justifiaient une partie de son rôle historique commencent, elles, à bouger.

Numeum rapporte en juin 2026 que le modèle de régie au TJM est « de plus en plus concurrencé » par des engagements de capacité, de résultat ou de gain partagé. Cette publication est une restitution de forum réunissant une soixantaine de dirigeants du secteur, et non une étude représentative : elle constitue donc un signal de marché, pas la preuve de la disparition de la régie.

Une tension comparable existe dans le conseil : lorsque l'IA réduit l'effort nécessaire à certaines productions, la valeur doit davantage être justifiée par l'impact, les actifs, le jugement ou l'exploitation continue que par le nombre d'heures consommées.

La conclusion la plus prudente est que le TJM peut rester une unité contractuelle pertinente dans de nombreux contextes, mais devient insuffisant comme justification unique de la valeur lorsqu'une prestation fortement automatisable nécessite nettement moins de jours.

Ce que cela change pour le commercial

Le Business Manager dont la valeur repose principalement sur trois capacités, obtenir un besoin, trouver un CV, négocier un TJM, est mécaniquement exposé lorsque le matching devient automatisable, que le client dispose lui-même de davantage d'information, qu'une équipe augmentée peut délivrer davantage avec moins de jours, et que les offres mélangent humains, agents, licences, consommation et services récurrents.

Le métier commercial devient alors plus difficile, pas plus simple.

Il faut être capable d'expliquer pourquoi un client devrait acheter une capacité de modernisation plutôt que quatre développeurs, comment la valeur sera mesurée, quel risque est transféré au fournisseur, quelles responsabilités restent au client et quels coûts technologiques entrent réellement dans la marge.

Le Business Manager doit comprendre davantage la production

C'est probablement le changement le plus profond.

Vendre un dispositif humain + agents sans comprendre comment il fonctionne expose l'ESN à deux erreurs opposées : promettre une productivité irréaliste ou restituer au client tout le gain sans savoir comment reconstruire la marge.

Le commercial doit donc comprendre au minimum quels travaux sont réellement automatisables, où demeure la review humaine, comment se mesure la qualité, ce qu'est une baseline, combien coûtent modèles, licences et exploitation, comment fonctionne un engagement de capacité ou d'outcome, quelles dépendances client rendent un résultat difficile à garantir, et quels actifs restent propriété de l'ESN.

Le Business Manager devient ainsi moins vendeur d'une quantité de travail que concepteur d'un contrat de création de valeur.

Les indicateurs doivent suivre

Si l'entreprise continue à rémunérer principalement ses commerciaux sur le volume de jours placés, elle aura du mal à leur demander simultanément de vendre des équipes plus petites, des actifs ou des abonnements.

À terme, il devient pertinent d'ajouter au chiffre d'affaires et à la marge la part de revenu récurrent, le renouvellement, la marge après coûts IA et licences, l'usage d'actifs réutilisables, l'expansion du compte, la transformation d'un pilote en contrat, et la valeur effectivement obtenue lorsque celle-ci peut être mesurée.

Quatre métiers, une transformation commune : la responsabilité remonte

La lecture transversale fait apparaître un déplacement plus intéressant que le débat sur les suppressions de postes.

L'IA ne supprime pas d'abord ces quatre métiers. Elle attaque la partie de chacun qui consistait à produire, coordonner ou rapprocher de l'information standard. La valeur remonte vers celui qui définit le contexte, vérifie la qualité, tranche les exceptions et assume le résultat.

Cette thèse reste à challenger.

Pourquoi cette thèse peut être trop simple

Toutes les organisations ne se transforment pas. Lucca illustre une adoption de l'IA sans refonte fondamentale des équipes. Pennylane continue de recruter fortement et valorise l'expertise comptable au cœur de son produit. Installer de l'IA ne produit donc pas automatiquement de nouveaux rôles.

Les gains de productivité sont très variables. DORA invite à raisonner sur le système organisationnel plutôt que sur l'outil isolé, tandis que METR montre qu'un outil IA peut même ralentir certains développeurs dans certains contextes. Il serait donc imprudent de reconstruire une organisation sur l'hypothèse fixe de « 30 % de productivité supplémentaire ».

Certaines activités standard restent nécessaires pour apprendre. Une tâche peut devenir économiquement automatisable tout en restant pédagogiquement utile. C'est particulièrement important pour les développeurs et les recruteurs : si un junior ne lit plus de code simple ou ne mène plus jamais de qualification initiale, comment acquiert-il les schémas qui lui permettront demain de détecter une mauvaise réponse de l'IA ? Les professionnels expérimentés disposent des repères nécessaires pour repérer certaines erreurs que les plus jeunes n'ont pas encore acquis.

Réinventer ne signifie pas généraliser. Un développeur sur un legacy critique n'évoluera pas au même rythme qu'un ingénieur dans une startup AI-native. Un recruteur de dirigeants n'a pas le même travail qu'une équipe Talent Acquisition devant traiter plusieurs milliers de candidatures. Un Business Manager vendant une expertise cyber rare n'est pas confronté au même problème qu'un commercial positionnant des développeurs standard en régie.

La bonne unité de transformation n'est donc pas le métier dans son ensemble : c'est le portefeuille de tâches, de décisions et de responsabilités à l'intérieur du métier.

Auto-diagnostic : votre métier est-il réellement en train d'être réinventé ?

Pour chacun de vos métiers clés, répondez aux douze questions suivantes.

• •Avons-nous identifié précisément les tâches dont le volume diminue avec l'IA ?
• •Savons-nous quelles tâches restent nécessaires pour apprendre le métier, même si elles pourraient être automatisées ?
• •Avons-nous défini ce que l'IA peut produire seule, ce qu'un humain doit vérifier et ce qu'un humain doit décider ?
• •Les indicateurs actuels récompensent-ils encore une activité devenue largement automatisable ?
• •Avons-nous identifié les nouvelles compétences réellement nécessaires, au-delà de la simple « maîtrise de l'IA » ?
• •Nos managers savent-ils évaluer la qualité d'un travail produit avec un agent ?
• •Un junior peut-il encore acquérir les repères nécessaires pour devenir senior ?
• •Nos parcours de carrière correspondent-ils encore à la manière dont le travail se fait réellement ?
• •Nos recrutements testent-ils la capacité de jugement et d'apprentissage, ou essentiellement les connaissances historiques du métier ?
• •Nos commerciaux comprennent-ils suffisamment le nouveau delivery pour vendre autre chose que des ressources et du temps ?
• •Avons-nous une baseline permettant de vérifier que l'IA améliore réellement délai, qualité ou coût complet ?
• •Pourrions-nous expliquer simplement à un collaborateur ce qui fera sa valeur dans trois ans si la moitié de ses tâches actuelles change ?

Si vous répondez « non » à plus de quatre questions, le sujet n'est probablement plus d'ajouter quelques formations IA. Il devient nécessaire de revisiter le design même du métier : tâches, responsabilités, mesure de la performance, apprentissage et trajectoire.

Pour conclure

Développeur, chef de projet, recruteur et Business Manager ne sont pas quatre métiers condamnés. Ce sont quatre métiers dont la partie la plus répétable devient moins suffisante pour justifier la valeur.

Pour le développeur, la bascule est déjà fortement visible. Pour le recruteur, elle se dessine clairement autour du matching et de l'évaluation. Pour le chef de projet et le Business Manager, elle relève encore davantage d'une hypothèse organisationnelle : si le delivery et les modèles de vente changent réellement, leurs responsabilités devront changer avec eux.

Le risque serait d'attendre que les intitulés bougent pour commencer à agir.

Les organisations ont plutôt intérêt à reconstruire dès maintenant les tâches, indicateurs et parcours, tout en acceptant qu'une partie des hypothèses devra être corrigée au fur et à mesure que les données s'accumulent.

Optimiser séparément chaque maillon de la chaîne, le Business Manager qui promet, le chef de projet qui organise, le développeur qui produit et garantit, le recruteur qui construit la capacité humaine, peut produire une organisation paradoxale : très efficace pour délivrer aujourd'hui, mais incapable de vendre autrement, de contrôler ce qu'elle produit ou de fabriquer ses futurs experts. La transformation réussie n'est donc pas celle qui automatise le plus de tâches. C'est celle qui redessine simultanément le travail, les compétences, les indicateurs et les parcours d'apprentissage.