Méthodes & Leadership

Transformation agile en entreprise : pourquoi elle s’essouffle (et ce que les dirigeants refusent de changer)

Les sprints tournent, les boards sont à jour, tout le monde parle de backlog. Et pourtant, rien ne va plus vite. Mike Cohn vient de mettre des mots sur ce mal très répandu : l’organisation a changé ses réunions, pas ses conditions. Décryptage sans bullshit, et un plan pour relancer la machine.

Votre transformation agile a démarré il y a deux ou trois ans. Il y a eu les formations, les coachs, les nouveaux rôles, les premiers sprints pleins d’énergie. Aujourd’hui, les équipes font toujours du Scrum. Les daily ont lieu, les rétrospectives aussi. Mais les décisions restent lentes, les priorités changent toutes les deux semaines et les équipes peinent à terminer ce qui compte vraiment. L’agile est partout dans le vocabulaire et presque nulle part dans les résultats.

Le 10 novembre 2026, Mike Cohn (cofondateur de la Scrum Alliance et de l’Agile Alliance, auteur de User Stories Applied) a publié sur Mountain Goat Software un texte qui circule déjà beaucoup chez les coachs : Why Agile Initiatives Lose Momentum. Son diagnostic tient en une phrase : une initiative agile cale quand l’organisation adopte les pratiques agiles sans changer les conditions qui déterminent si ces pratiques fonctionnent.

Ce sujet revient en force pour une raison simple : beaucoup d’entreprises ont fini leur « programme de transformation », ont démobilisé leurs coachs et regardent maintenant l’IA comme la prochaine vague. Avant de repeindre la façade une nouvelle fois, il vaut la peine de comprendre pourquoi la précédente n’a pas tenu. On reprend les trois causes identifiées par Cohn, les quatre changements qu’il attend des dirigeants, et on ajoute notre lecture Corporate Mavericks.

Le symptôme : l’agilité de façade

Une transformation agile qui s’essouffle ne ressemble pas à un échec. Elle ressemble à un succès figé. Les cérémonies sont tenues, les tableaux Kanban sont remplis de post-its, les rôles de Product Owner et de Scrum Master existent sur l’organigramme. Vu de loin, tout est conforme. C’est précisément ce qui rend le problème si difficile à détecter.

Mike Cohn propose un test très simple : comparer les changements visibles avec les changements opérationnels.

La colonne de gauche peut aider, mais elle ne crée pas d’agilité à elle seule. Les vraies questions sont dans la colonne de droite : les décisions se rapprochent-elles du terrain ? Sait-on qui décide quoi ? Les arbitrages sont-ils faits plus tôt et plus honnêtement ? L’organisation apprend-elle plus vite de ses utilisateurs ? Si la réponse est non, vous avez changé de méthodologie, pas de fonctionnement.

Cause n°1 : le process change, le leadership ne change pas

Le scénario est connu. L’entreprise adopte Scrum ou un autre framework agile, crée des backlogs, demande aux équipes de livrer par itérations. Mais les hypothèses profondes restent les mêmes. Les managers continuent d’attribuer le travail. Les dirigeants continuent de valider les solutions. Les équipes sont évaluées sur leur taux d’occupation. Il faut toujours une permission pour prendre des décisions qui devraient se prendre au plus près du travail.

Cohn insiste sur un point que beaucoup de comités de direction préfèrent ignorer : les dirigeants ne peuvent pas déléguer leur part de l’agilité. On demande aux équipes de devenir agiles, on nomme des Scrum Masters, on finance des formations, parfois on crée un bureau de transformation. Mais une grande partie des obstacles rencontrés par les équipes ne sont pas des obstacles d’équipe. Une équipe ne peut pas décider du nombre d’initiatives actives dans l’entreprise. Elle ne peut pas donner à son Product Owner une autorité que la direction lui refuse. Elle ne peut pas empêcher que ses membres soient éparpillés sur plusieurs projets. Elle ne peut pas changer seule le budget, les incitations ou le reporting.

L’exemple qu’il raconte est terriblement banal. Un comité exécutif soutient l’agile « en principe » : il finance le coaching, envoie les gens en formation, en parle positivement. Mais aucun dirigeant ne vient aux sprint reviews. Personne ne demande ce que les équipes ont appris des clients ni quels résultats s’améliorent. La seule question posée est : est-ce que tout le monde est occupé à 100 % ? Les équipes ont parfaitement compris le vrai message. Ce qui compte, ce n’est pas d’apprendre plus vite, c’est d’avoir l’air débordé.

La situation a changé le jour où un dirigeant a commencé à assister aux reviews de façon régulière en posant trois questions : quel problème client avons-nous traité ? Qu’avons-nous appris ? Que devons-nous faire ensuite à cause de ce que nous avons appris ? Ces questions ont modifié ce que les équipes préparaient et ce à quoi tout le monde prêtait attention.

« Quand les dirigeants restent en dehors du changement, l’organisation reçoit un message clair : nous voulons que les équipes travaillent autrement, mais nous n’allons pas changer grand-chose autour d’elles. »

Mike Cohn, Mountain Goat Software, 10 novembre 2026 (traduction Corporate Mavericks)

Marre des transformations qui changent le vocabulaire et jamais les décisions ? Chaque semaine, on décortique ce qui marche vraiment dans les organisations.

Cause n°2 : l’agilité à l’échelle avant l’agilité tout court

Deuxième piège : l’organisation étend l’agile avant d’avoir un modèle qui fonctionne et qui mérite d’être répliqué. On forme plus d’équipes, on ajoute des tableaux et des réunions, on passe des départements entiers en itérations. Sans jamais répondre à une question plus basique : est-ce que l’agile fonctionne quelque part, ici, aujourd’hui ?

C’est souvent le moment où arrivent les grands frameworks de mise à l’échelle, le copier-coller du modèle Spotify (que Spotify lui-même n’a jamais présenté comme un modèle à reproduire) et les trains de release. Si quelques équipes ne savent pas déjà livrer régulièrement de la valeur, apprendre des retours et s’améliorer, la mise à l’échelle ne fait que répandre les mêmes problèmes plus loin. Cohn le formule ainsi : l’organisation obtient plus d’activité agile sans devenir plus agile.

Répliquer les conditions, pas les pratiques

La meilleure séquence consiste à créer quelques réussites, à comprendre pourquoi elles marchent, puis à diffuser les conditions de ce succès. Regardez vos équipes qui fonctionnent bien et posez-vous ces questions :

• Ont-elles des priorités claires ?

• Une seule personne a-t-elle la responsabilité finale des décisions produit ?

• Peuvent-elles terminer un travail important avant d’en commencer un autre ?

• Leurs managers les protègent-ils des interruptions permanentes ?

• Les décisions peuvent-elles être prises au plus près du travail ?

• Reçoivent-elles un retour utile assez tôt pour agir dessus ?

Ce sont ces conditions qui valent la peine d’être répliquées. La bonne question n’est pas « comment faire passer plus d’équipes à l’agile ? » mais « qu’est-ce qui a fait marcher l’agile pour ces équipes, et comment créer ces conditions ailleurs ? ».

Occupé n’est pas productif

Parmi ces conditions, Cohn met en avant la focalisation. Face à une livraison lente, beaucoup d’organisations réagissent en lançant davantage de chantiers. On ajoute des initiatives, on insère des demandes urgentes, on répartit les gens sur plusieurs projets pour que chaque sujet important « avance un peu ». Résultat prévisible : plus de changements de contexte, plus d’attente, plus de dépendances, plus de coordination. Tout est commencé, presque rien n’est fini. C’est exactement ce que la limitation du travail en cours, au coeur de Kanban et du lean, cherche à éviter.

Son exemple : une entreprise où presque tout le monde était affecté à trois ou quatre projets en même temps. Du point de vue de la direction, c’était efficace, personne n’était inactif. Du point de vue des équipes, c’était épuisant. Du point de vue du système, c’était un embouteillage. Nous avions décrit ce mécanisme dans notre article sur le sur-engagement des équipes, et il s’aggrave avec l’IA : quand produire du code devient presque gratuit, la tentation de tout lancer en parallèle explose, comme on l’a vu avec le paradoxe de Jevons.

La leçon la plus contre-intuitive

÷ 2

Dans l’entreprise décrite par Mike Cohn, la sortie de l’embouteillage n’est venue ni d’un recrutement, ni d’un effort supplémentaire. La direction a réduit de presque moitié le nombre d’initiatives actives. Le travail a enfin pu se terminer, et la livraison s’est améliorée. Si dire non ne fait mal à personne, vous n’avez pas priorisé : vous avez seulement réordonné la liste.

Cause n°3 : personne ne tranche les décisions produit

Beaucoup de problèmes qui ressemblent à des problèmes de livraison sont en réalité des problèmes de décision produit. L’organisation a quelqu’un avec le titre de Product Owner, mais très peu d’autorité pour arbitrer. Les priorités se négocient entre managers, dirigeants, parties prenantes, architectes, commerciaux et l’auteur de la dernière demande urgente. Que beaucoup de gens donnent leur avis est sain. Le problème commence quand beaucoup de gens pensent aussi avoir le dernier mot.

Les arbitrages deviennent politiques. L’équipe construit ce qui est le plus récent, le plus bruyant ou soutenu par le sponsor le plus haut placé. Le backlog devient un entrepôt de demandes plutôt que l’expression d’une stratégie produit. Les stories sont livrées, la vélocité est comptée, les releases sortent. Mais une question devient impossible à trancher : livrons-nous les bonnes choses ?

Cohn raconte le cas d’une organisation où le rôle de Product Owner tournait entre plusieurs parties prenantes. À chaque sprint, quelqu’un d’autre était aux commandes. Les objectifs de sprint devenaient instables, les priorités bougeaient en cours de route et les équipes ont cessé de croire au plan. La direction voyait un problème de livraison. L’organisation avait un problème de responsabilité. Dès qu’un Product Owner unique a été nommé et protégé, l’équipe s’est améliorée très vite, non parce qu’elle était devenue plus intelligente, mais parce qu’elle avait enfin une direction cohérente. Si le sujet vous parle, notre analyse sur l’avenir du Product Owner face à l’IA prolonge la réflexion : quand plus personne ne peut dire non, plus personne ne possède vraiment le résultat.

Quand l’agilité rend les problèmes visibles, ce n’est pas un échec

C’est sans doute le passage le plus utile pour un comité de direction. Ces trois causes deviennent souvent plus visibles après l’adoption de l’agile. Les plans changent, les équipes remontent davantage de problèmes, les mauvaises décisions produit sont questionnées. On découvre plus tôt que les clients ne veulent pas une fonctionnalité autant qu’on le pensait. L’entreprise a l’air plus désordonnée qu’avant.

Cohn décrit une équipe de direction qui avait conclu, après quelques mois, que « l’agile ne marchait pas ». Mais l’agile n’avait rien créé. Les équipes construisaient déjà des choses dont les clients ne voulaient pas. Les priorités étaient déjà instables. Les retours arrivaient déjà avec des mois de retard, et tout le monde trouvait ça normal. L’agilité a seulement rendu ces conditions visibles plus tôt. Inconfortable, mais précieux : c’est une information qui permet d’agir pendant qu’il est encore temps.

On retrouve ici une idée que nous défendons depuis longtemps : quand une transformation cale, il est tentant d’accuser la résistance au changement des équipes. Nous avons expliqué dans notre article sur l’échec de la transformation digitale pourquoi ce diagnostic est presque toujours trop confortable pour ceux qui le posent.

Relancer une transformation agile : les 4 changements que les dirigeants doivent faire

Les organisations en meilleure santé ont aussi des problèmes, prennent aussi de mauvaises décisions et découvrent aussi que leurs plans étaient faux. La différence est dans la réponse. Elles ne confondent pas visibilité et échec, ni activité et progrès. Et elles ne demandent pas aux équipes de changer pendant que les dirigeants continuent exactement comme avant. Concrètement, Cohn identifie quatre changements de posture.

1. Participer de façon visible

Pas pour piloter le travail quotidien des équipes, mais pour ne plus rester en dehors du changement. Venir aux reviews, demander des résultats et des apprentissages, chercher les obstacles organisationnels que les équipes ne peuvent pas lever seules. Et le faire dans la durée. Quand les collaborateurs pensent que l’agile est « l’initiative du trimestre », beaucoup attendent que ça passe en gardant l’ancien fonctionnement sous le nouveau vocabulaire. Une visite isolée en sprint review se remarque. Une présence répétée change ce que les gens croient que la direction valorise.

2. Donner un vrai pouvoir de décision

L’empowerment ne se décrète pas en nommant un Product Owner. Il demande trois choses : l’autorité de prendre les décisions qu’exige le rôle, le temps de bien le tenir, et la confiance quand une décision devient inconfortable. Quand chaque décision significative remonte la hiérarchie pour validation, l’apprentissage ralentit et la responsabilité se dilue. La formule de Cohn mérite d’être affichée dans toutes les salles de comité : une responsabilité sans autorité, ce n’est pas de l’empowerment.

3. Focaliser le système

Relancer l’élan ne veut pas dire tout relancer. Réduire le nombre de priorités actives, protéger les équipes des interruptions inutiles, laisser le travail important se terminer avant d’en ajouter. Toute entreprise a plus de bonnes idées que de capacité. La question difficile n’est pas de savoir quelles idées ont de la valeur (la plupart en ont), mais lesquelles vont attendre, lesquelles vont s’arrêter, et lesquelles l’organisation accepte de ne pas faire maintenant. Prioriser vraiment ferme des portes et déçoit des gens. C’est le prix à payer pour finir quelque chose qui compte. La vitesse vient de la capacité à terminer.

4. Traiter l’agile comme un système d’apprentissage

Beaucoup de frustrations viennent du fait qu’on fait semblant d’avoir des certitudes qui n’existent pas. Les dirigeants exigent des garanties que personne ne peut honnêtement donner, les équipes répondent avec plus d’assurance qu’elles n’en ont, puis la réalité arrive et tout le monde fait mine d’être surpris. L’approche saine consiste à prendre la meilleure décision possible avec l’information disponible, tout en restant prêt à s’adapter. Quatre questions suffisent pour rendre un plan plus honnête : que savons-nous ? Qu’est-ce qui reste incertain ? Qu’espérons-nous apprendre ensuite ? Quelle fourchette de résultats est raisonnable ?

La méthode : un changement significatif à la fois

Une transformation agile qui cale n’a généralement pas besoin d’un nouveau grand déploiement, d’un rebranding ou d’un nouveau programme de transformation. Elle a besoin qu’on s’attaque aux contraintes que les équipes ne peuvent pas lever seules. La démarche proposée par Cohn est d’une simplicité désarmante, ce qui la rend difficile à appliquer pour les organisations habituées aux plans à dix chantiers :

1. Identifier la contrainte qui génère le plus de retard, de perturbation ou de confusion.

2. Choisir un changement significatif qu’un dirigeant peut faire lui-même.

3. Faire ce changement, au lieu d’annoncer un « soutien renouvelé ».

4. Observer si le flux, l’apprentissage ou la livraison s’améliorent.

5. Recommencer avec la contrainte suivante.

Ce changement peut consister à donner au Product Owner l’autorité sur une décision qui exige aujourd’hui une escalade. À arrêter une initiative moins prioritaire pour que l’important se termine. À supprimer un obstacle organisationnel que les équipes remontent depuis des mois en rétrospective. Bref, de l’amélioration continue appliquée à l’organisation elle-même, et pas seulement aux équipes.

Notre lecture sans bullshit

Le texte de Mike Cohn est solide, et on le partage largement. Trois remarques pour le lire avec du recul.

• Ce sont des retours d’expérience, pas une étude. Les exemples sont anonymes et non chiffrés. Ils sonneront juste pour quiconque a vécu une transformation agile, mais ils ne prouvent rien statistiquement. À vous de vérifier dans votre propre environnement, avec vos propres données de flux (délai de livraison, travail en cours, taux de changement de priorités en cours de sprint).

• L’auteur vend aussi un atelier pour dirigeants. Ça n’invalide pas le propos, mais ça explique l’angle : tout ramène au leadership. C’est souvent vrai. Ce n’est pas toujours suffisant : un système d’information rigide, des contrats au forfait ou une architecture monolithique peuvent aussi tuer l’agilité, quelle que soit la bonne volonté de la direction.

• Le vrai sujet, c’est l’organisation, pas la méthode agile. Scrum, Kanban, SAFe ou le prochain framework à la mode ne changent rien si la structure de décision reste identique. C’est la leçon de l’approche sociotechnique : une bonne pratique meurt dans une mauvaise organisation. Et c’est encore plus vrai à l’heure où les entreprises veulent intégrer des agents IA dans leurs équipes sans avoir réglé qui décide de quoi.

Si l’on devait résumer l’article en une phrase à glisser dans votre prochain comité de direction : les initiatives agiles calent rarement parce que les équipes ont oublié comment tenir un daily. Elles calent parce que l’entreprise a cessé de changer les conditions qui avaient rendu l’agilité nécessaire. Avant de demander aux équipes de changer davantage, les dirigeants doivent regarder lesquels de leurs propres comportements doivent changer ensuite. C’est là que commence l’agilité.

FAQ : transformation agile en entreprise

Le plus souvent, parce que l’entreprise change ses pratiques (réunions, rôles, outils) sans changer ses conditions de fonctionnement. Mike Cohn identifie trois causes récurrentes : le leadership ne change pas sa façon de décider et d’évaluer, l’agilité est étendue à toute l’organisation avant de fonctionner quelque part, et les décisions produit restent floues, sans Product Owner réellement habilité à trancher. La résistance au changement des équipes est rarement la cause principale.Scrum est le framework agile le plus répandu : des sprints courts, un Product Owner, un Scrum Master et une équipe de développement. Kanban, issu du lean, se concentre sur la visualisation du flux et la limitation du travail en cours. On croise aussi l’Extreme Programming (XP) pour les pratiques techniques, et des frameworks de mise à l’échelle comme SAFe ou LeSS. Aucune méthode agile ne garantit le résultat : c’est l’organisation autour qui fait la différence.L’agilité à l’échelle désigne l’extension des pratiques agiles au-delà d’une équipe, à plusieurs équipes, un programme ou toute une entreprise, souvent avec des frameworks comme SAFe, LeSS ou Nexus. Le piège classique est de mettre à l’échelle avant d’avoir des équipes qui fonctionnent vraiment. Mieux vaut d’abord comprendre ce qui fait réussir quelques équipes (priorités claires, autonomie de décision, focalisation) puis répliquer ces conditions.Ce sont les quatre valeurs du Manifeste agile publié en 2001 : les individus et leurs interactions plus que les processus et les outils, des logiciels opérationnels plus qu’une documentation exhaustive, la collaboration avec les clients plus que la négociation contractuelle, et l’adaptation au changement plus que le suivi d’un plan. Le manifeste précise que les éléments de droite ont de la valeur, mais que ceux de gauche en ont davantage.Il n’existe pas de liste officielle, mais on retrouve presque toujours les mêmes principes : décentraliser la décision au plus près du travail, donner aux équipes l’autorité qui va avec leurs responsabilités, limiter le nombre de priorités pour finir avant de commencer, favoriser l’apprentissage par des boucles de retour courtes, et mesurer les résultats pour les utilisateurs plutôt que l’occupation des gens. Le Management 3.0 de Jurgen Appelo en propose une déclinaison très concrète.Pas avec un nouveau programme. Identifiez la contrainte organisationnelle qui crée le plus de retard ou de confusion, choisissez un changement qu’un dirigeant peut faire lui-même (donner une autorité réelle au Product Owner, arrêter une initiative moins prioritaire, lever un obstacle remonté depuis longtemps), faites-le, mesurez l’effet sur le flux et la livraison, puis passez à la contrainte suivante. La participation visible des dirigeants aux sprint reviews envoie aussi un signal décisif.

Sources : Mike Cohn, Why Agile Initiatives Lose Momentum, and How to Get Them Moving Again, Mountain Goat Software, 10 novembre 2026 (citations et exemples traduits par Corporate Mavericks) ; Manifeste pour le développement agile de logiciels, 2001.

L’agilité ne se déploie pas. Elle se mérite, décision après décision.

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management, la transformation et l’IA au travail, sans jargon et sans bullshit.

Culture & Organisation

Communication asynchrone : votre équipe se noie en réunions, et ce n’est pas Slack qui va la sauver

Synchrone ou asynchrone ? La question paraît technique, elle est profondément managériale. Ce qu’elle révèle : votre rapport au temps des autres, à la confiance et au contrôle. Mode d’emploi sans bullshit pour passer à l’async sans casser le lien.

Le 9 novembre 2026, le blog d’Atlassian (Loom) a republié un guide au titre très simple : Synchronous vs Asynchronous Communication. Rien de révolutionnaire en apparence. Et pourtant, le sujet de la communication asynchrone revient dans toutes les conversations de dirigeants que nous croisons : équipes hybrides, agendas saturés, journées passées à « faire des points » plutôt qu’à travailler, managers qui confondent présence et performance.

La communication asynchrone, c’est toute forme d’échange où il existe un décalage entre le moment où l’on envoie un message et le moment où le destinataire le traite : un document partagé, un commentaire dans un ticket, une vidéo courte, un e-mail réfléchi. La communication synchrone, à l’inverse, se déroule en temps réel : réunion, appel, visio, discussion de couloir. Quelle est la différence en pratique ? Dans le premier cas, chacun avance quand cela lui convient ; dans le second, il faut d’abord synchroniser les agendas.

Le problème n’est pas de choisir un camp. Le problème, c’est que la plupart des organisations n’ont jamais choisi du tout. Par défaut, tout devient réunion. Et quand on veut « faire de l’async », on remplace les réunions par un flux de messages instantanés auquel chacun doit répondre dans la minute. On a changé d’outil, pas de culture. Dans cet article, on voit ce que la communication asynchrone change vraiment, quand l’utiliser, quand l’éviter, et comment un manager peut la mettre en place sans transformer son équipe en archipel de solitudes.

Communication synchrone et asynchrone : quelle différence ?

La différence tient en un mot : le temps réel. Le guide d’Atlassian la résume ainsi : la communication synchrone se produit quand plusieurs personnes échangent de l’information au même moment, en présentiel ou à distance, de façon planifiée ou improvisée. La communication asynchrone implique un délai entre l’envoi et la lecture, ce qui laisse au destinataire la liberté de répondre plus tard. On parle aussi de communication différée.

Un détail que beaucoup d’équipes ratent : l’outil ne définit pas le mode. Une messagerie instantanée où tout le monde attend une réponse immédiate, c’est du synchrone déguisé. Le guide classe d’ailleurs les fils de discussion en temps réel sur Slack du côté synchrone. À l’inverse, une visio enregistrée et regardée le lendemain devient de l’asynchrone. Ce qui compte, c’est l’attente implicite de réponse : faut il répondre tout de suite, ou peut on traiter le message sans attendre de réponse de l’autre côté ?

Pourquoi la communication asynchrone revient en force en 2026

Trois forces poussent les entreprises à repenser leur mode de collaboration.

1. La fatigue des réunions est devenue un coût visible

Les réunions d’information descendante (le fameux point hebdo où une personne parle et quinze écoutent) mobilisent un temps collectif énorme pour un contenu qui tiendrait dans une page. Le guide d’Atlassian cite une étude publiée sur PubMed Central qui mesure un gain de temps moyen de 58,8 % avec des méthodes asynchrones par rapport aux canaux synchrones traditionnels. Prudence : cette étude porte sur un contexte précis, le chiffre n’est pas transposable tel quel à votre équipe. Mais l’ordre de grandeur dit quelque chose.

2. Le travail profond ne survit pas aux interruptions

Chaque notification qui exige une réponse immédiate casse le flux de travail.

Les travaux de Gloria Mark (Université de Californie à Irvine) sur les interruptions au travail sont régulièrement cités : il faut en moyenne environ 23 minutes pour revenir pleinement à une tâche après une distraction. Multipliez par le nombre de notifications et de « tu as deux minutes ? » d’une journée, et vous comprenez pourquoi tant de gens disent ne travailler vraiment qu’avant 9 h ou après 18 h. Le travail asynchrone protège les plages de concentration et permet aux membres de l’équipe d’organiser leur journée de travail à leur propre rythme.

3. L’hybride a cassé l’unité de lieu et de temps

Équipes réparties sur plusieurs sites, temps partiels, horaires décalés, collègues à l’étranger : chercher un créneau commun devient un sport. Quand une organisation s’acharne à tout faire en synchrone, elle ralentit au rythme de l’agenda le plus chargé. Pour les équipes hybrides et celles qui travaillent sur plusieurs fuseaux horaires, la communication en temps réel devient l’exception, pas la règle. Nous avons déjà montré que le débat sur le retour au bureau cache souvent un besoin de contrôle plus qu’un besoin de collaboration. L’async pose la question inverse : comment collaborer sans avoir besoin d’être au même endroit au même moment ?

Une réunion d’information, c’est un email qui a pris huit agendas en otage. Un mode asynchrone sans règles, c’est une réunion permanente qui ne dit pas son nom.Le point de vue Corporate Mavericks

Le piège : croire que l’async, c’est « plus de messages »

Voici le scénario que nous voyons le plus souvent. Une direction annonce qu’elle veut « moins de réunions ». Les réunions disparaissent du calendrier, mais pas le besoin de coordination. Résultat : il migre dans la messagerie. Les notifications explosent, chacun garde l’outil ouvert en permanence par peur de rater quelque chose, et la pression de réponse immédiate devient pire qu’avant. On a remplacé une heure de réunion par huit heures de disponibilité.

Un travail asynchrone efficace repose sur trois choses que l’outil ne fournit pas :

• Une culture de l’écrit : savoir rédiger un message autoportant, avec le contexte, la question précise et l’échéance. Un « on en parle ? » n’est pas de l’async, c’est une réunion en attente.

• Des droits de décision clairs : si personne ne peut trancher sans réunir tout le monde, l’asynchrone n’aboutit jamais. Qui décide quoi doit être explicite.

• Des délais de réponse assumés : l’équipe doit savoir ce qui attend une réponse dans l’heure, dans la journée ou dans la semaine. Sans cette convention, tout devient urgent, donc rien ne l’est.

Autre angle mort : l’écrit amplifie les malentendus. Selon une enquête de Loom et Wakefield Research citée dans le guide, les salariés classent la messagerie instantanée (42 %) et l’email (34 %) parmi les canaux les plus propices aux incompréhensions. Le ton, l’ironie, un emoji mal interprété : en travail à distance, sans expressions faciales ni voix, un message neutre peut sembler sec. C’est une raison de mieux écrire, pas de revenir au tout réunion.

Moins de réunions, plus d’impact ?

Chaque semaine, on décortique une pratique de management qui fonctionne vraiment (et celles qui font juste joli dans un slide).

Synchrone ou asynchrone : comment choisir ? Les 5 questions à se poser

Le guide d’Atlassian propose une grille simple que nous trouvons utile, à condition de la poser explicitement en équipe plutôt que de laisser chacun improviser. Avant d’envoyer une invitation, posez vous ces cinq questions.

1. Combien de personnes doivent recevoir le message ?

Large audience ou agendas impossibles à aligner : asynchrone. Petit groupe qui doit dialoguer, ou message qui ne peut pas attendre la prochaine réunion : synchrone.

2. Ai-je besoin d’interaction ?

Une annonce, un point d’avancement, une validation de lancement : asynchrone. Un brainstorming, un arbitrage où chacun doit pouvoir objecter, la résolution d’un blocage : synchrone.

3. Quelle est l’urgence réelle ?

Le quotidien supporte un délai de réponse : asynchrone. Une panne qui touche les clients, un départ brutal dans l’équipe, une crise : synchrone, immédiatement.

4. Quelle est la complexité du sujet ?

Un sujet complexe mais explicable (un bug, une procédure, un retour sur un livrable) gagne souvent à être expliqué en vidéo courte ou par écrit structuré. Un sujet complexe qui demande de vérifier la compréhension en direct mérite un échange en temps réel.

5. Le risque de malentendu est-il élevé ?

Message simple et sans enjeu : écrit asynchrone. Message chargé émotionnellement (feedback difficile, changement d’organisation, tension relationnelle) : synchrone, ou au minimum une vidéo où l’on voit votre visage et entend votre voix.

La règle d’or que nous en tirons : l’asynchrone par défaut pour l’information, le synchrone par choix pour la relation et la décision difficile. Utiliser le mode écrit pour annoncer une réorganisation ou recadrer quelqu’un, c’est fuir la conversation. Utiliser une réunion pour lire des slides, c’est gaspiller le temps des autres.

Comment mettre en place une communication asynchrone efficace : la méthode en 6 étapes

Étape 1 : faire l’inventaire des réunions récurrentes

Listez toutes les réunions récurrentes de l’équipe et classez les en trois colonnes : celles qui produisent des décisions, celles qui servent le lien et la coordination, celles qui ne font que diffuser de l’information. La troisième colonne est votre premier gisement pour réduire le nombre de réunions. Un point d’avancement peut devenir un fil écrit partagé chaque lundi, où chacun indique ce qui avance, ce qui bloque, et ce dont il a besoin.

Étape 2 : écrire une charte de communication d’équipe

Une page suffit. Quel canal pour quoi (messagerie pour les questions rapides, outil de gestion de projet pour le suivi, documents pour les décisions), quel délai de réponse attendu sur chaque canal, quelles plages sont protégées sans notification. Loom utilise par exemple des niveaux de priorité : P0 pour une réponse dès que possible, P1 avec une échéance précise, P2 pour un message non urgent. Copiez l’idée, adaptez les mots.

Étape 3 : apprendre à écrire pour être lu

Communiquer efficacement à l’écrit s’apprend. Un bon message asynchrone commence par la demande, pas par l’historique. Il précise le contexte nécessaire, la décision ou l’action attendue, la date limite et la personne qui tranche. Un test simple : un collègue qui revient de congés comprend il le message sans poser de question ? Si non, réécrivez.

Étape 4 : documenter les décisions, pas seulement les échanges

L’un des avantages majeurs de l’asynchrone est la trace écrite. Encore faut il qu’elle soit trouvable. Un journal de décisions (la décision, la date, qui a décidé, pourquoi, quelles options ont été écartées) évite de rouvrir les débats tous les trois mois et accélère l’intégration des nouveaux arrivants.

Étape 5 : utiliser la vidéo courte pour ce qui demande de la nuance

Entre le message écrit sec et la réunion d’une heure, il existe un entre deux : la vidéo de deux ou trois minutes où l’on montre son écran et où l’on parle. Selon la même enquête Loom et Wakefield Research, 70 % des salariés estiment qu’une courte vidéo aurait évité leur dernier malentendu. C’est un chiffre produit par un éditeur de vidéo, donc à lire avec recul, mais l’intuition est juste : la voix transporte l’intention.

Étape 6 : garder (et soigner) les moments synchrones

Passer à l’async ne veut pas dire supprimer toute rencontre. Au contraire : moins de réunions de diffusion, c’est plus d’énergie pour les moments qui comptent. Rétrospective, atelier de conception, résolution de conflit, célébration d’une réussite, café d’équipe : ces temps synchrones nourrissent la confiance. Sans eux, l’équipe devient une somme d’individus qui se passent des fichiers, un travers que nous décrivions à propos des équipes qui travaillent comme des individus.

Les meilleurs outils de communication asynchrone (et comment bien les utiliser)

Les outils de communication ne créent pas une culture, mais un mauvais usage peut la détruire. Voici les cinq familles de méthodes de communication asynchrone les plus répandues, avec la règle d’usage qui va avec.

• L’e-mail : pour les échanges formels, avec des personnes extérieures ou quand il faut une trace. Un objet explicite, une demande claire en première ligne.

• La messagerie d’équipe (Slack, Microsoft Teams) : pour les questions rapides, à condition d’accepter qu’une réponse puisse attendre. Des fils thématiques plutôt qu’un canal fourre tout.

• Les outils de gestion de projet (Jira, Trello, Asana) : pour le suivi du travail. Le statut d’une tâche se lit dans l’outil, pas dans une réunion.

• La base de connaissances (Confluence, Notion) : pour les décisions, les procédures et tout ce qu’un nouvel arrivant doit pouvoir retrouver seul.

• La communication vidéo asynchrone (Loom et équivalents) : pour expliquer, démontrer ou faire un retour nuancé sans bloquer un créneau. Idéal pour présenter une maquette à un utilisateur ou à un client et recueillir son feedback.

Quand choisir lequel ? Une règle simple : plus l’information doit durer, plus elle doit vivre dans un document ; plus elle est éphémère, plus elle peut rester dans la messagerie. Et pour collaborer sur un sujet qui exige de vraies interactions, rien ne remplace un échange en direct.

Ce que la communication asynchrone change pour le manager

C’est ici que le sujet devient vraiment intéressant. Le synchrone permanent arrange beaucoup de managers, parce qu’il donne une illusion de contrôle : je vois les gens, je les entends, donc je sais où on en est. L’asynchrone retire cette béquille. Il oblige à piloter par les résultats et non par la présence.

• Clarifier plutôt que surveiller. Des objectifs explicites, des priorités écrites, des critères de « terminé » partagés : c’est ce qui permet à chacun d’avancer sans attendre une validation orale.

• Déléguer pour de vrai. Si chaque arbitrage remonte au manager, l’async crée des files d’attente. Les décisions doivent se prendre au plus près du travail.

• Rendre la parole plus équitable. En réunion, ce sont souvent les plus rapides et les plus sûrs d’eux qui occupent l’espace (nous en parlions à propos du fait de couper la parole en réunion). L’écrit donne du temps aux introvertis, aux non natifs, à ceux qui réfléchissent avant de parler.

• Limiter la pensée de groupe. Recueillir les avis par écrit avant d’en débattre évite que tout le monde s’aligne sur la première opinion exprimée, un antidote simple à la pensée de groupe.

• Surveiller l’isolement. Le revers de l’asynchrone, c’est la solitude. Un manager attentif garde des tête à tête réguliers en temps réel, surtout avec les nouveaux arrivants et les personnes en difficulté.

Les 6 erreurs qui tuent la communication asynchrone

1. Annoncer l’async sans changer les attentes de réactivité. Si le manager répond en trente secondes à 22 h, l’équipe comprendra que c’est la norme, quelle que soit la charte.

2. Écrire des romans. L’asynchrone n’est pas une invitation au mur de texte. Structurez : demande, contexte, options, échéance.

3. Traiter les sujets humains par écrit. Un feedback négatif, une mauvaise nouvelle, un conflit : en face à face ou en visio, jamais par message. Respectez aussi les styles de communication de chacun : certains ont besoin de parler pour réfléchir.

4. Multiplier les canaux. Cinq outils où l’information peut se cacher, c’est cinq endroits à surveiller. Moins de canaux, mieux rangés.

5. Ne jamais clore les fils. Une discussion asynchrone doit se terminer par une décision écrite et une personne responsable. Sinon, elle tourne indéfiniment.

6. Supprimer tout le synchrone. Une équipe qui ne se voit plus perd la confiance qui rend l’écrit fluide. L’async efficace repose sur une relation construite en direct.

Le test à lancer dès lundi

Choisissez une réunion récurrente d’information. Pendant quatre semaines, remplacez la par un fil écrit structuré (trois questions : ce qui a avancé, ce qui bloque, ce dont j’ai besoin), avec une échéance fixe chaque semaine. Gardez quinze minutes en direct uniquement pour traiter les blocages remontés. À la fin, demandez à l’équipe : avons nous perdu de l’information ? Avons nous gagné du temps ? Qu’est ce qui nous a manqué ? Vous aurez une réponse fondée sur l’expérience plutôt que sur une opinion.

FAQ : communication asynchrone

La communication asynchrone désigne tout échange dans lequel il existe un délai entre l’envoi d’un message et sa lecture ou sa réponse. Le destinataire traite l’information à son rythme. Emails, documents partagés, commentaires dans un outil de gestion de projet, wikis ou vidéos enregistrées en sont des exemples.La communication synchrone se déroule en temps réel : réunion, appel, visio, discussion en face à face. L’asynchrone laisse un décalage entre l’émission et la réception. Ce n’est pas l’outil qui fait la différence mais l’attente de réponse : une messagerie où tout le monde doit répondre immédiatement reste du synchrone.Les principaux outils de communication asynchrone sont l’e-mail, la messagerie d’équipe utilisée en mode différé (Slack, Microsoft Teams), les outils de gestion de projet (Jira, Trello, Asana), les bases de connaissances (Confluence, Notion) et la communication vidéo asynchrone (Loom). Le choix de l’outil compte moins que les règles d’usage partagées par l’équipe.Avantages : moins d’interruptions, plus de temps de concentration, collaboration facilitée entre fuseaux horaires et horaires différents, trace écrite des décisions, parole plus équitable. Inconvénients : lenteur des allers retours, risque de malentendu à l’écrit, sentiment d’isolement si les moments en direct disparaissent, inadaptation aux crises et aux sujets sensibles.Commencez par une charte d’équipe qui précise quel canal utiliser pour quoi et le délai de réponse attendu sur chacun. Transformez une réunion d’information en point écrit, documentez les décisions dans un endroit unique, apprenez à rédiger des messages autoportants et conservez des temps synchrones réguliers pour le lien et les arbitrages difficiles.Elle convient à la plupart des équipes pour l’information et le suivi, mais pas pour tout. Les situations de crise, les conflits, les annonces sensibles et la création collective restent mieux servis par le synchrone. Une équipe très récente ou en tension aura aussi besoin de davantage de moments en direct pour construire la confiance.

En résumé : l’async n’est pas un outil, c’est une marque de respect

Choisir l’asynchrone par défaut, c’est reconnaître que le temps et l’attention de vos collègues ont de la valeur. Choisir le synchrone à bon escient, c’est reconnaître que certaines conversations ne se délèguent pas à un message. Échanger des informations de manière asynchrone, se coordonner sans synchronisation permanente, réserver les sessions de brainstorming aux vrais sujets collectifs : c’est ainsi qu’on construit un environnement de travail sain. Les équipes qui s’en sortent le mieux ne sont pas celles qui ont le plus d’outils, mais celles qui ont explicité leurs règles du jeu, et dont les managers les respectent eux mêmes en premier.

Alors, avant votre prochaine invitation de réunion, une seule question : est ce que ça aurait pu être un message bien écrit ?

Source principale : Julia Szatar, Synchronous vs Asynchronous Communication, Atlassian Blog (Loom), 9 novembre 2026. Les chiffres (58,8 % de gain de temps, 23 minutes de reconcentration, enquête Loom et Wakefield Research) sont cités d’après ce guide.

Votre agenda mérite mieux que des réunions qui auraient dû être un email

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management, la culture et la transformation, sans jargon et sans bullshit.

Transformation & IA

Reskilling : IKEA a requalifié 8 500 salariés remplacés par l’IA au lieu de les licencier

Un chatbot a absorbé les questions répétitives du service client. Plutôt que de couper dans les effectifs, IKEA a formé ses conseillers à un autre métier. Résultat : son canal de vente le plus dynamique. Décryptage sans bullshit, et une méthode pour faire pareil dans votre équipe.

Le 1er novembre 2026, Eric Ries (l’auteur de The Lean Startup) a consacré sa newsletter à une histoire qui circule beaucoup chez les dirigeants depuis l’été : What IKEA did with 8,500 employees replaced by AI. Le sous-titre tient en quatre mots : ils n’ont licencié personne. C’est probablement le cas de reskilling le plus documenté de l’ère de l’IA générative, et il prend le contre-pied exact de ce que font la plupart des entreprises quand elles automatisent.

Le reskilling, c’est le fait de former des collaborateurs à un autre poste que le leur, parce que leur métier actuel est en train de disparaître ou de se transformer. Pendant des années, le mot est resté coincé dans les slides RH. Avec l’IA, il devient une question de compétitivité, et une question de management très concrète : que faites-vous des gens dont une machine vient de prendre une partie du travail ?

Dans cet article, on regarde ce qu’IKEA a réellement fait (chiffres sourcés), pourquoi ça a marché, ce que l’histoire ne dit pas, et comment un manager peut lancer un programme de reskilling sans attendre un grand plan stratégique venu d’en haut.

Reskilling et upskilling : quelle différence ?

Les deux termes sont souvent mélangés, alors posons les bases.

• L’upskilling, c’est la montée en compétences dans son propre métier : un comptable qui apprend à piloter un outil d’automatisation, un développeur qui apprend à travailler avec un agent de code. Le poste reste le même, il devient plus exigeant.

• Le reskilling, c’est l’acquisition de nouvelles compétences pour occuper un autre poste, souvent dans la même entreprise. C’est une forme de reconversion interne : le conseiller qui répondait aux questions sur les horaires d’ouverture devient conseiller en aménagement intérieur.

Upskilling et reskilling ne s’opposent pas. Dans la plupart des programmes sérieux, on fait les deux : on renforce les compétences existantes et on ouvre des passerelles vers de nouveaux rôles. La différence est surtout dans l’intention. L’upskilling protège un poste. Le reskilling protège une employabilité, celle du salarié sur le marché du travail, et celle de l’entreprise qui garde des gens qui connaissent ses clients, ses produits et sa culture.

L’histoire d’IKEA : un chatbot, 8 500 conseillers, zéro licenciement

En 2021, Ingka Group (la société qui exploite la majorité des magasins IKEA dans le monde) lance un assistant conversationnel baptisé Billie, clin d’oeil à la célèbre bibliothèque Billy. Sa mission : traiter les questions répétitives qui saturent les centres d’appels depuis que le Covid a fait exploser la vente en ligne. « À quelle heure ouvre le magasin ? », « Est-ce que je peux venir avec mon chien ? ». Selon Ingka, entre 2021 et 2023, Billie a résolu environ 47 % des demandes et généré près de 13 millions d’euros d’économies. D’après l’enquête de Fortune publiée en juillet 2026, le bot aide désormais 74 % des clients qui l’utilisent.

Jusque-là, rien d’original. L’automatisation du service client est devenue un classique. Le scénario attendu, c’est la suite logique du tableur : moins d’appels pour les humains, donc moins d’humains.

IKEA a fait autre chose. L’entreprise a requalifié environ 8 500 conseillers de ses centres d’appels. Une partie traite désormais les demandes complexes que le bot ne sait pas résoudre (litiges de livraison, montage de systèmes modulaires). Les autres sont devenus conseillers en design d’intérieur à distance : ils aident les clients à planifier une cuisine, un salon, une chambre, par téléphone ou en visio. Ces équipes travaillent depuis 24 centres de vente à distance qui couvrent les 31 pays où Ingka est présent.

Le chiffre qui change la conversation

1,25 Md€

C’est le chiffre d’affaires réalisé par les centres de vente à distance d’IKEA sur le dernier exercice, contre 1,08 milliard l’année précédente. Ce canal, animé par les conseillers requalifiés, est le plus dynamique du groupe depuis trois ans, avec une croissance de 15 à 20 % par an. L’indice interne de satisfaction client est passé de 60 % avant Billie à 89 %.

Pourquoi la plupart des entreprises font exactement l’inverse

Fortune le formule sans détour : alors que tant d’entreprises mesurent le succès de leur adoption de l’IA au nombre de dépenses qu’elles coupent et de salariés dont elles se séparent, IKEA traite la technologie comme un moyen de libérer ses équipes pour un travail à plus forte marge. Le contraste mérite qu’on s’y arrête, parce qu’il révèle un biais de pilotage très répandu.

Le premier biais, c’est la métrique. Quand le ROI d’un projet d’IA est calculé en équivalents temps plein supprimés, la seule issue possible est la réduction d’effectifs. Les économies sont visibles et immédiates, la valeur perdue (relation client, connaissance produit, capacité à vendre) ne figure dans aucun tableau de bord. Nous avions détaillé ce piège dans notre article sur le ROI de l’IA : ce qu’on mesure finit par décider à la place des dirigeants.

Le deuxième biais, c’est l’horizon. Un plan de départs se boucle en un trimestre. Un programme de reskilling demande du temps : chez IKEA, il a fallu deux ans pour requalifier les 8 500 conseillers, au rythme où Billie montait en puissance. Dans une entreprise pilotée au trimestre, deux ans, c’est une éternité.

Le troisième biais, c’est la peur. Selon une enquête mondiale de Mercer menée en février 2026 auprès de 12 000 salariés et dirigeants, citée par Fortune, 40 % des salariés craignent que l’IA rende leur poste obsolète, contre 28 % en 2024. Une équipe qui a peur se protège, retient l’information et résiste au changement. Le Forum économique mondial estime de son côté que 92 millions d’emplois pourraient être supprimés d’ici 2030 sous l’effet de l’IA, des technologies associées et de la démographie, que 170 millions de nouveaux rôles pourraient apparaître, et que près de 40 % des compétences demandées au travail vont changer. Autrement dit : les nouveaux postes existeront, mais pas forcément pour les mêmes personnes, sauf si quelqu’un organise la passerelle.

Le cas Klarna sert souvent de contre-exemple. Le spécialiste suédois du paiement fractionné avait mis en avant son assistant IA capable de faire le travail de centaines d’agents, avant de reconnaître en 2025 une baisse de qualité du service et de réintroduire des conseillers humains. Couper vite coûte parfois plus cher que former lentement.

Vous en avez assez des transformations IA qui se résument à un tableau d’ETP supprimés ? Chaque semaine, on décortique ce qui marche vraiment, chiffres à l’appui.

Les 5 leviers qui ont fait marcher le reskilling chez IKEA

1. Couper le journal d’appels en deux

Forbes résume très bien la logique : une fois le journal d’appels séparé en deux, tout devient simple. Les questions qu’un bot traite facilement sont rarement liées à une vente. Celles qu’il ne sait pas traiter le sont souvent. « Quelle couleur de canapé avec mon salon ? » ne se règle pas avec un script, ça demande du jugement, du goût, de l’écoute. IKEA n’a pas cherché un nouveau métier au hasard : il a regardé ce que le bot laissait de côté et a constaté que c’était précisément la partie qui rapportait.

2. Miser sur les compétences adjacentes

Pour Prasanna Tambe, professeur à Wharton interrogé par Fortune, la clé d’un reskilling réussi est d’identifier et d’exploiter les adjacences de compétences. Un conseiller de centre d’appels connaît déjà le catalogue, les process de livraison, les irritants des clients. Il sait gérer un interlocuteur mécontent. Lui apprendre la conception d’une cuisine part d’une base solide, bien plus qu’un recrutement externe sur un profil de designer qui ne connaît ni l’entreprise, ni ses clients.

3. Former sur le concret, pas sur des slides

Les conseillers sont devenus experts des outils numériques de planification d’IKEA, en présentiel et en ligne. Ils ont appris à mener un entretien de conception, des questions techniques (mesures, couleurs) jusqu’aux questions plus fines : « Qu’est-ce qui ne fonctionne pas dans cette pièce ? », « Comment vous sentez-vous dedans ? ». Un conseiller de Sheffield raconte à Fortune avoir suivi une « école de la cuisine » de deux semaines et être allé en magasin étudier les plans de travail de près. Aujourd’hui, le parcours de formation d’un nouvel arrivant dure cinq à six semaines.

4. Rattacher le nouveau rôle à une valeur mesurable

Le reskilling d’IKEA n’est pas un geste social déguisé : il est branché sur un indicateur business. Les conseillers ont accompagné 10 millions de clients sur le dernier exercice, et le canal pèse plus d’un milliard d’euros. Quand un programme de formation produit un résultat que la direction financière peut lire, il cesse d’être un centre de coût qu’on rabote à la première alerte budgétaire.

5. Une gouvernance qui protège le long terme

C’est le point sur lequel insiste Eric Ries. Ingka appartient à une fondation, une structure voulue par Ingvar Kamprad pour que la mission de l’entreprise lui survive. Fortune note que ce statut privé donne à IKEA le luxe d’expérimenter sur les prix et sur les personnes sans craindre la réaction des actionnaires d’une société cotée. Ries rappelle au passage une vieille leçon du lean manufacturing : les gens ne sont pas des ressources, ce sont des actifs qu’on entretient et qu’on développe. Toyota le dit à sa façon : « nous fabriquons des personnes, pas seulement des voitures ».

« Pendant très longtemps, les entreprises ont utilisé les gens pour répondre à ce dont les clients ont besoin. La question est : existe-t-il une occasion de les déplacer vers ce que les clients veulent ? »

Prasanna Tambe, professeur à la Wharton School, interrogé par Fortune (traduction Corporate Mavericks)

Ce que le cas IKEA ne dit pas (lecture sans bullshit)

Un bon cas d’école se lit avec ses angles morts. En voici quatre, tous issus des mêmes sources.

• Le canal reste petit. Selon Forbes, la vente à distance représente environ 3 % du chiffre d’affaires d’Ingka (près de 47,8 milliards de dollars sur l’exercice 2025). En 2023, l’entreprise visait 10 % d’ici 2028. Le succès est réel, l’objectif n’est pas atteint.

• IKEA licencie aussi. Au printemps 2026, Ingka et Inter IKEA ont supprimé plusieurs centaines de postes au siège pour rester compétitifs sur les prix. Aucun de ces départs ne concernait les centres de vente à distance, ni n’était attribué à l’IA, mais l’entreprise n’est pas un sanctuaire.

• La suite n’est pas garantie. Interrogé sur l’avenir, le directeur digital d’Ingka, Parag Parekh, n’a pas exclu de futures réductions d’effectifs, en précisant qu’elles dépendraient plutôt du contexte économique que de l’IA. Rien n’empêche Billie de monter encore en compétence.

• Le contexte est favorable. Un catalogue immense, des projets d’aménagement coûteux et chargés d’émotion : le conseil humain a ici une valeur évidente. Dans un métier où le bot couvre 100 % de la valeur, la passerelle est plus difficile à trouver.

Rien de tout cela n’invalide le cas. Cela rappelle simplement qu’un programme de reskilling n’est pas une promesse d’emploi à vie. C’est un pari sur le fait que des gens formés et qui connaissent la maison créent plus de valeur que l’économie de leur salaire. Et ce pari se pilote.

Comment lancer un programme de reskilling dans votre équipe : la méthode en 6 étapes

Vous n’êtes pas IKEA, vous n’avez pas 8 500 conseillers ni une fondation pour actionnaire. Bonne nouvelle : la logique fonctionne aussi à l’échelle d’une équipe de quinze personnes. Voici une démarche que tout manager peut engager avec ses RH.

1. Cartographier les tâches, pas les postes. Listez ce que l’automatisation absorbe déjà ou absorbera dans les 18 mois : saisie, reporting, réponses de premier niveau, synthèses. Un poste disparaît rarement d’un coup, il se vide par morceaux.

2. Chercher où va la valeur libérée. Posez la question d’IKEA : qu’est-ce que l’outil ne sait pas faire, et qu’est-ce que nos clients (internes ou externes) seraient prêts à payer ? Conseil, résolution de cas complexes, relation, qualité, coordination.

3. Inventorier les compétences existantes. Avant de recruter, regardez ce que vos collaborateurs savent déjà faire. Les compétences adjacentes (connaissance client, maîtrise produit, soft skills) sont le meilleur point de départ d’une reconversion interne.

4. Construire un parcours concret et progressif. Formation continue courte, mises en situation, binômes avec des experts, terrain. Calez le rythme sur celui de l’automatisation, comme IKEA l’a fait avec Billie. En France, le plan de développement des compétences et le dispositif Pro-A (reconversion ou promotion par alternance) peuvent financer une partie des actions de formation.

5. Annoncer tôt et clairement. Le silence nourrit la peur. Dire « voilà ce que l’outil va prendre, voilà vers quoi on vous propose d’aller » change complètement la dynamique. C’est aussi une question de sens au travail : nous avons montré dans notre article sur le sens au travail que l’IA peut emporter ce que les gens aimaient dans leur métier si personne ne réfléchit à la suite.

6. Mesurer en valeur, pas en effectifs. Choisissez deux ou trois indicateurs reliés au nouveau rôle : chiffre d’affaires généré, satisfaction client, délai de résolution, taux de mobilité interne. Sans ça, votre programme sera le premier sacrifié à la prochaine revue budgétaire.

Le reskilling n’est pas un sujet RH, c’est un sujet de management

Les RH conçoivent les dispositifs, gèrent les budgets de formation, sécurisent le cadre légal. Mais c’est le manager qui voit, semaine après semaine, quelles tâches disparaissent, quelles compétences émergent et quels collaborateurs ont envie d’aller plus loin. C’est lui qui libère du temps pour apprendre, qui protège ce temps quand la charge monte et qui accepte une baisse de productivité temporaire pendant la transition.

C’est aussi lui qui doit refuser la facilité. Ne plus former les profils débutants parce que l’IA fait leur travail, c’est scier la branche sur laquelle reposera la prochaine génération d’experts. Nous en avons parlé à propos du développeur junior face à l’IA, et le raisonnement vaut pour tous les métiers. Les entreprises qui investissent aujourd’hui dans le développement professionnel de leurs équipes ne font pas de la philanthropie : elles évitent la pénurie de talents de demain et réduisent leur dépendance au recrutement externe.

Enfin, c’est un sujet de cohérence. Une direction qui annonce que « l’humain est au coeur de la stratégie IA » tout en pilotant le projet au nombre de postes supprimés perd sa crédibilité en une seule réunion. Si vous voulez éviter ce piège, regardez aussi le vrai coût de l’IA en entreprise : il ne se limite jamais à la licence.

FAQ : reskilling, upskilling et IA

L’upskilling désigne la montée en compétences d’un salarié dans son poste actuel, pour suivre l’évolution de son métier. Le reskilling consiste à acquérir de nouvelles compétences pour occuper un autre poste, souvent dans la même entreprise, quand le métier d’origine se transforme ou disparaît, par exemple sous l’effet de l’automatisation.La reconversion professionnelle est un changement de métier, souvent à l’initiative du salarié et parfois hors de son entreprise. Le reskilling est généralement piloté par l’employeur : il organise la formation et la mobilité interne vers des rôles dont l’entreprise a besoin. C’est une reconversion accompagnée, qui préserve l’employabilité du collaborateur et les compétences de l’organisation.Commencez par identifier les tâches de votre métier que l’IA prend déjà en charge, puis les compétences que vous possédez et qui restent rares : relation client, jugement, connaissance d’un domaine. Parlez-en à votre manager et à vos RH avant de chercher ailleurs : un parcours de reskilling interne, financé par l’employeur, est souvent plus rapide qu’une reconversion externe. En France, le CPF et le dispositif Pro-A peuvent compléter le financement.Cela dépend de l’écart entre l’ancien et le nouveau poste. Chez IKEA, la requalification de 8 500 conseillers s’est étalée sur deux ans, au rythme de la montée en puissance du chatbot. Aujourd’hui, la formation d’un nouveau conseiller en design dure cinq à six semaines. Un programme réaliste combine quelques semaines de formation intensive et plusieurs mois d’accompagnement sur le terrain.Il peut l’être si le nouveau rôle est rattaché à une valeur mesurable. Le canal de vente à distance animé par les conseillers requalifiés d’IKEA a généré 1,25 milliard d’euros sur le dernier exercice, avec une croissance de 15 à 20 % par an. À l’inverse, un programme de formation déconnecté des besoins de l’entreprise reste un coût. La clé : mesurer la valeur créée, pas seulement les heures de formation.Le manager repère les tâches qui disparaissent et les compétences qui émergent, libère et protège du temps pour apprendre, accompagne la montée en compétences sur le terrain et rend visibles les résultats. Les RH conçoivent les dispositifs, mais sans implication du manager, un programme de reskilling reste théorique.

Sources : Eric Ries, What IKEA did with 8,500 employees replaced by AI, 1er novembre 2026 ; Claire Zillman, Inside Ikea’s big bet on humans in the age of AI, Fortune, 30 juillet 2026 ; Noemi Kis, IKEA Retrained 8,500 Call Center Workers Into Design Sales After AI, Forbes, 5 octobre 2026. Les données Mercer et Forum économique mondial sont citées d’après Fortune.

L’IA libère du temps. À vous de décider ce que vous en faites.

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management, la transformation et l’IA au travail, sans jargon et sans bullshit.

Paradoxe de Jevons : l’IA rend le code gratuit, et l’effet rebond transforme votre équipe en usine à features

En 1865, un économiste anglais montrait que des machines plus efficaces faisaient brûler plus de charbon, pas moins. En 2026, vos agents de code rejouent exactement le même film. Décryptage sans bullshit, et cinq questions pour ne pas finir en usine à fonctionnalités.

Le 8 novembre 2026, Stefan Wolpers (Professional Scrum Trainer, auteur du Scrum Anti-Patterns Guide) a publié sur Age of Product un texte au titre provocateur : We’re Not Paid to Practice Scrum, but Answer 5 Product Questions. Son point de départ tient en une idée que tout dirigeant devrait méditer : pendant des décennies, le coût élevé du développement logiciel jouait un rôle de rationnement. Personne ne pouvait tout construire, donc quelqu’un devait choisir. L’IA a fait sauter ce garde-fou. Et ce qui se passe ensuite porte un nom bien connu des économistes : le paradoxe de Jevons.

Quand une ressource devient moins chère à utiliser, on ne l’économise pas : on en consomme davantage. Le code ne fait pas exception. Les agents IA ont fait chuter le coût d’une fonctionnalité, donc les organisations en lancent plus, en livrent plus, en maintiennent plus. Mais personne n’a vérifié si ces fonctionnalités résolvaient un vrai problème client.

Cet article vous explique d’où vient ce paradoxe, ce qu’est l’effet rebond, pourquoi il frappe aujourd’hui vos équipes produit, et comment reprendre la main avec cinq questions simples que l’IA ne posera jamais à votre place.

Qu’est-ce que le paradoxe de Jevons ?

En 1865, l’économiste britannique William Stanley Jevons publie The Coal Question. À l’époque, la Grande-Bretagne tire sa puissance industrielle du charbon, et une inquiétude monte : les réserves vont-elles s’épuiser ? Beaucoup pensent que le progrès technique va régler le problème. La machine à vapeur, perfectionnée depuis James Watt, consomme de moins en moins de charbon pour le même travail. Une meilleure efficacité devrait donc faire baisser la consommation de charbon.

Jevons démontre l’inverse. Chaque amélioration de l’efficacité rend la vapeur plus rentable, donc utilisable dans de nouveaux secteurs, de nouvelles usines, de nouveaux usages. La consommation totale de charbon ne baisse pas : elle explose. Comme le résume le projet Energy History de l’université Yale, pour Jevons, une efficacité accrue de la consommation ne réduit pas la demande d’énergie.

Voilà le paradoxe de Jevons en une phrase : un gain d’efficacité sur une ressource peut provoquer une augmentation de la consommation de cette ressource, au lieu de la réduction attendue. Ce n’est pas une loi physique, c’est un mécanisme économique, qui dépend du marché et de la demande. Mais quand la demande est élastique, il frappe fort.

Effet rebond direct, rebond indirect, effet Jevons : les nuances à connaître

Les économistes de l’énergie parlent aujourd’hui d’effet rebond pour décrire ce phénomène, et distinguent plusieurs niveaux :

• L’effet rebond direct : le bien devenu plus efficace est utilisé davantage. Une voiture plus sobre coûte moins cher au kilomètre, donc on roule plus. Une partie des économies d’énergie promises s’évapore.

• Le rebond indirect : l’argent économisé est dépensé ailleurs, dans d’autres biens et services qui consomment eux aussi des ressources.

• L’effet Jevons (ou « backfire ») : le cas extrême où le rebond dépasse 100 %. La consommation totale finit plus haute qu’avant l’amélioration. C’est ce que Jevons observait avec le charbon.

C’est pour cela que l’efficacité énergétique, seule, ne suffit pas toujours à faire baisser la demande énergétique ou les émissions de CO2 : sans changement des comportements, une partie des gains d’efficacité est mangée par la hausse des usages. Retenez cette mécanique. Elle va nous servir pour parler de votre backlog.

La version 2026 : le prix du code s’effondre

Stefan Wolpers cite deux chiffres qui donnent le vertige. Selon Epoch AI (étude The plunging price of thought, septembre 2026), le coût d’un niveau donné de performance IA aurait baissé d’environ 47 % par trimestre sur cinq benchmarks, une estimation que ses auteurs eux-mêmes demandent de ne pas lire comme exacte. Et dans le document d’introduction en bourse d’Anthropic (formulaire S-1 d’octobre 2026), on lit une phrase que Jevons aurait reconnue : des coûts par tâche plus bas entraînent un usage plus important, qui entraîne à son tour une diffusion plus large.

Traduction pour un comité de direction : vos fournisseurs d’IA ont besoin que vous en consommiez toujours plus. Ce n’est pas une accusation, c’est leur modèle économique. Mais ce n’est pas forcément le vôtre.

Le paradoxe de Jevons appliqué à l’IA : ce qui ne grossit pas avec vos agents

Soyons honnêtes : la baisse du coût de construction est une excellente nouvelle. Des problèmes clients qui n’étaient pas rentables à résoudre le deviennent. Un prototype monté en un après-midi est une manière légitime de tester si un client s’intéresse vraiment à une idée. Le problème n’est pas l’efficacité. Le problème, c’est ce qui ne suit pas.

Car plusieurs ressources ne se multiplient pas avec le nombre d’agents :

• L’attention de vos clients. Ils ne lisent pas plus de release notes parce que vous en écrivez plus.

• Leur capacité à absorber le changement. Dix nouvelles fonctionnalités par mois, c’est dix choses à apprendre, ou à ignorer.

• Votre capacité de revue. Le rapport DORA 2025 sur le développement assisté par IA décrit l’IA comme un amplificateur des forces et des faiblesses existantes d’une organisation, et constate que l’instabilité des livraisons continue d’augmenter. DORA ajoute un mécanisme que tout relecteur connaît : le gain de vitesse de l’auteur se transforme souvent en charge cognitive accrue pour celui qui relit.

• Votre capacité à maintenir, sécuriser et supporter tout ce qui a été livré. Le code généré en deux heures coûte toujours des années de maintenance.

Quand la décision de lancer un chantier repose sur le coût de la première version, les économies visibles captent toute l’attention et les coûts de cycle de vie disparaissent du radar. Nous avions déjà décrit ce mirage dans notre article sur le vibe coding en entreprise : tout le monde code avec l’IA, plus personne ne trie.

Vous aussi, vous en avez assez des transformations qui empilent les outils sans changer les décisions ? Chaque semaine, on décortique ce qui marche vraiment.

Les 5 questions produit que l’effet rebond rend impossibles à esquiver

Wolpers résume depuis des années son métier par une phrase que nous adorons chez Corporate Mavericks : nous ne sommes pas payés pour pratiquer Scrum, mais pour résoudre les problèmes de nos clients dans les contraintes données, tout en contribuant à la pérennité de l’organisation. Quand construire ne coûte presque plus rien, cinq questions deviennent beaucoup plus chères à sauter :

1. Quel problème client mérite d’être résolu ?

La réponse a deux faces : pourquoi le client s’en soucie, et pourquoi le résoudre vaut le coup pour l’organisation. Uri Levine, cofondateur de Waze, en a fait le titre de son livre de 2023 : Fall in Love with the Problem, Not the Solution. Quand le code est gratuit, tomber amoureux de sa propre solution redevient abordable. Méfiance aussi avec l’IA qui « résume » trois cents tickets support en trois problèmes : elle a déjà décidé ce qu’elle gardait et ce qu’elle jetait.

2. Est-ce la meilleure utilisation de notre temps, maintenant ?

Les nouvelles fonctionnalités sont en concurrence avec la maintenance, la fiabilité, la dette technique et le support. Et dans un comité, la maintenance perd toujours face à une fonctionnalité brillante. Le bon affinage d’un backlog ne produit pas des tickets jolis (c’est justement ce qu’un agent produit le plus vite), il produit une compréhension partagée suffisante pour décider, y compris de ne pas construire.

3. Est-ce assez bon pour les gens qui vont le voir ?

« Assez bon » dépend de l’objectif. Un prototype pour apprendre et du code destiné à la production n’ont pas le même standard, mais chacun doit en avoir un. Le vrai danger : ne plus savoir distinguer la sonde jetable du produit, et voir le prototype de deux heures partir en production « parce qu’il marche déjà ». Après la vingtième sortie d’agent de la journée, « ça a l’air bien » devient le seul critère de qualité. Ce n’est pas un critère.

4. Est-ce que ça a résolu le problème ?

L’output se compte facilement : tickets fermés, fonctionnalités livrées, story points brûlés. Aucun de ces chiffres ne dit si le problème du client a diminué. Wolpers propose un exemple simple : une équipe veut réduire le nombre de nouveaux clients qui décrochent pendant l’onboarding, et un agent construit une visite guidée en deux jours. Avant de livrer, l’équipe écrit quatre choses : la situation de départ (la part actuelle de clients qui abandonnent avant leur premier résultat utile), le changement qui justifierait de garder la fonctionnalité, la période d’observation (plusieurs semaines) et les règles de décision (garder, modifier ou supprimer). Ce dernier point est celui que tout le monde saute, parce que supprimer quelque chose qui « marche » ressemble à du gaspillage.

5. Notre façon de travailler est-elle toujours la bonne ?

C’est la question que l’IA bouleverse le plus, parce que la façon de travailler change à chaque nouveau modèle et à chaque nouvel agent. La rétrospective existe pour ça. Wolpers recommande d’y ajouter un audit régulier des tâches déléguées à l’IA, avec un signal d’alerte précis : quand le temps de revue par livrable tend vers zéro, l’assistance est silencieusement devenue de l’automatisation non relue.

Le chiffre qui pique

1 sur 26

Dans l’enquête menée par Stefan Wolpers en août 2026 auprès de 48 praticiens, seul 1 des 26 répondants dont l’organisation avait adopté (ou adoptait) le « product operating model » rapportait un changement fondamental dans la façon de décider quoi construire. 9 décrivaient surtout un changement d’étiquettes, 9 un mélange des deux, 7 jugeaient trop tôt pour le dire.

Mettre le vocabulaire sur les slides est facile. Changer qui décide, et sur quelles preuves, est difficile.

Où les équipes se plantent (et pourquoi l’IA aggrave chaque erreur)

Chacune des cinq questions a son échec classique, et l’IA les rend tous moins chers à commettre :

• Quel problème ? La demande du directeur saute l’entonnoir et arrive dans le backlog avec une deadline, parce que la hiérarchie pèse plus lourd que les preuves.

• Meilleur usage du temps ? Un backlog bien rangé passe pour un bon affinage, et la maintenance perd tous ses arbitrages.

• Assez bon ? La fatigue de revue s’installe, et on valide à l’œil.

• Ça a marché ? La Sprint Review devient une démo, les parties prenantes applaudissent l’incrément au lieu de demander ce qui a changé pour le client.

• Comment on travaille ? Personne n’a le temps d’inspecter sa façon de travailler, tout le monde est occupé à livrer ce que les agents ont produit.

L’usine à features commence précisément là : quand une équipe considère qu’une livraison réussie prouve que le choix était bon. C’est la même illusion que nous dénoncions à propos du ROI de l’IA : la courbe de vélocité monte, et personne ne sait si la valeur suit.

Comment éviter l’effet rebond dans votre organisation : 6 leviers concrets

Vous ne stopperez pas la baisse du coût du code, et ce n’est pas souhaitable. En revanche, vous pouvez éviter que ce gain d’efficacité se transforme en augmentation de la consommation de l’attention de vos équipes et de vos clients.

1. Posez une limite de travail en cours sur la revue, pas sur la production. Le vrai goulot n’est plus le développement, c’est ce que l’équipe peut relire et mesurer correctement par cycle. Une limite explicite rend ce plafond visible, quel que soit le nombre de pull requests ouvertes par les agents.

2. Étiquetez chaque élément : sonde ou produit. Un prototype sert à apprendre, il a son propre standard et une date de péremption. Il ne part jamais en production sans repasser par la Definition of Done.

3. Écrivez les règles de décision avant de livrer. Situation de départ, seuil de succès, durée d’observation, conséquence (garder, modifier, supprimer). Sans ça, tout résultat sera interprété comme un succès.

4. Donnez un standard aux livrables IA. Une analyse, un rapport ou des tickets rédigés par un agent méritent un critère d’acceptation écrit par ceux qui en sont responsables, avant de sortir de l’équipe.

5. Protégez le temps d’apprentissage. Erik Brynjolfsson, Daniel Rock et Chad Syverson ont décrit la « courbe en J » de la productivité des technologies généralistes comme l’IA : elles exigent des investissements immatériels (nouveaux processus, nouvelles compétences) qui font paraître la productivité plus faible au début. Juger trop vite, c’est condamner l’apprentissage comme une perte.

6. Donnez à quelqu’un le pouvoir de dire stop. C’est le levier le plus inconfortable, et le seul qui change vraiment le modèle opérationnel.

Ce dernier point rejoint le débat sur l’avenir du rôle de Product Owner face à l’IA : si personne n’a l’autorité de renoncer à construire, le rôle se réduit à alimenter des agents.

Le test à faire lundi matin : preuve, autorité, stop

Wolpers propose un exercice redoutable. Prenez les cinq questions en réunion d’équipe, et pour chacune demandez :

• Preuve : qui apporte aujourd’hui les éléments pour y répondre ?

• Autorité : qui a le pouvoir d’agir sur la réponse ?

• Stop : que se passe-t-il quand la réponse est « on arrête » ?

Si personne ne peut agir sur un « stop », vous avez trouvé la première question à traiter. Et peu importe que vous appeliez ça Scrum, product operating model ou autre chose : comme le dit Wolpers, tant que vous délivrez de la valeur de façon éthique, légale, durable et financièrement viable, personne ne se soucie de la méthode utilisée.

Ce qu’il faut retenir

Le paradoxe de Jevons n’est pas une curiosité d’historien de la machine à vapeur. C’est le mécanisme qui transforme aujourd’hui la baisse spectaculaire du coût du code en avalanche de fonctionnalités non triées. L’effet rebond n’est ni bon ni mauvais en soi : il devient toxique quand plus personne ne filtre ce qui mérite d’être construit.

Le coût élevé du développement faisait un tri grossier à votre place (souvent mal, d’ailleurs, car l’idée portée par le sponsor le plus haut placé survivait toujours). Ce tri a disparu. À vous de le remplacer par quelque chose de mieux : des questions explicites, des preuves, et le droit de dire non.

FAQ : paradoxe de Jevons, effet rebond et IA

C’est l’idée, formulée par l’économiste William Stanley Jevons en 1865 dans The Coal Question, qu’une amélioration de l’efficacité dans l’usage d’une ressource peut augmenter sa consommation totale au lieu de la réduire. Les machines à vapeur plus efficaces ont rendu le charbon plus rentable, donc on en a brûlé davantage.L’effet rebond désigne toute hausse de consommation qui grignote une partie des économies attendues d’un gain d’efficacité (rebond direct ou indirect). Le paradoxe de Jevons est le cas extrême où ce rebond dépasse 100 % : la consommation finale devient supérieure à celle d’avant l’amélioration.Il n’y a pas de durée type. Les économistes distinguent un rebond de court terme (les usages augmentent immédiatement) et un rebond de long terme (de nouveaux usages, de nouveaux marchés apparaissent). Avec l’IA, le phénomène est accéléré : selon Stefan Wolpers, les habitudes se figent en quelques mois, d’où l’intérêt de poser des règles de travail tôt.Les signaux vont dans ce sens : le coût d’un niveau de performance IA chute fortement selon Epoch AI, et Anthropic écrit dans son S-1 que des coûts par tâche plus bas entraînent un usage plus important. Pour une équipe produit, cela se traduit par plus de code, plus de fonctionnalités et plus de revue, sans hausse automatique de la valeur pour le client.En réintroduisant un filtre explicite : choisir le problème avant la solution, distinguer prototypes et code de production, fixer des règles de décision avant de livrer, limiter le travail en cours sur la revue, et donner à quelqu’un l’autorité de dire stop.Décrite par Brynjolfsson, Rock et Syverson, elle explique que les technologies généralistes comme l’IA exigent des investissements immatériels (processus, compétences) mal mesurés. La productivité mesurée paraît donc plus faible au début, puis meilleure ensuite. D’où le danger de juger trop vite une adoption de l’IA.

Source principale : Stefan Wolpers, We’re Not Paid to Practice Scrum, but Answer 5 Product Questions, Age of Product, 8 novembre 2026. Les chiffres Epoch AI, Anthropic S-1, DORA 2025 et l’enquête sur le product operating model sont cités d’après cet article.

Moins de features, plus d’impact

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management, la transformation et l’IA au travail, sans jargon et sans bullshit.

Approche sociotechnique : pourquoi la bonne techno meurt dans la mauvaise organisation

Vous avez choisi le meilleur outil, la meilleure architecture, la meilleure IA du marché. Et rien ne pousse. Le problème n’est pas la graine, c’est le sol. Décryptage sans bullshit d’une idée née dans les mines de charbon anglaises et plus actuelle que jamais.

Début novembre 2026, InfoQ a publié la transcription d’une conférence donnée à QCon London par Vanessa Formicola, responsable engineering passée par Microsoft, Thoughtworks et Flo Health : The Socio-Technical Staff+ Engineer: Architecture, Culture and Organisational Change. Son point de départ est une image qui parle à tous ceux qui ont vécu une transformation : un bananier planté dans un jardin d’Europe du Nord. Il est vivant. Personne ne peut dire que le choix de la plante était absurde. Mais il ne donnera jamais de bananes.

C’est exactement ce qui arrive quand une entreprise déploie une technologie, une méthode ou un outil sans regarder le terrain sur lequel elle le plante. Et c’est tout l’objet de l’approche sociotechnique : considérer qu’une organisation n’est pas un système technique sur lequel on pose des humains, mais un seul système où le social et le technique sont interdépendants. Changez l’un sans l’autre, et vous obtenez des bananiers sous la pluie.

Si vous êtes dirigeant, manager, architecte ou responsable d’une transformation (agile, data, IA), cet article vous donne les fondements de cette approche, ce qu’elle explique de vos échecs passés, et six leviers concrets pour l’appliquer.

Qu’est-ce que l’approche sociotechnique ?

L’approche sociotechnique naît au début des années 1950 au Tavistock Institute de Londres. Deux chercheurs, Eric Trist et Ken Bamforth, étudient les mines de charbon britanniques au moment où la méthode dite « longwall » mécanise l’extraction. Sur le papier, la nouvelle technologie devait faire exploser la productivité. Dans les faits, elle a cassé les petites équipes autonomes et polyvalentes qui organisaient elles-mêmes leur travail, remplacées par des postes spécialisés et cloisonnés. Résultat observé par Trist et Bamforth dans leur article de 1951 : tensions, absentéisme et une productivité qui ne suit pas.

Leur conclusion fonde toute la discipline : une organisation est composée d’un système technique (outils, machines, processus, logiciels) et d’un système social (personnes, relations, rôles, normes, pouvoir). Les deux sont en interdépendance permanente. Chercher l’optimisation du seul système technique dégrade le système social, et donc la performance globale. Il faut viser une optimisation conjointe des deux. Fred Emery, autre figure du Tavistock, formalisera ensuite ces principes de conception des systèmes sociotechniques (souvent abrégés STS).

Système sociotechnique, dispositif sociotechnique : de quoi parle-t-on ?

Un système sociotechnique désigne l’ensemble formé par une organisation, ses technologies et les personnes qui les utilisent. Un dispositif sociotechnique est un objet ou un agencement concret (un logiciel RH, un outil de ticketing, un process de validation) qui embarque des choix sociaux : qui décide, qui voit quoi, qui dépend de qui. La sociologue Madeleine Akrich a montré que tout objet technique contient un « script », une vision implicite de ses utilisateurs, que ceux-ci vont accepter, détourner ou rejeter. Bien avant elle, Gilbert Simondon (Du mode d’existence des objets techniques, 1958) invitait à ne pas penser la technique comme un simple outil neutre. L’appropriation d’une technologie est donc toujours une médiation, jamais une installation.

Traduction managériale : votre outil n’est pas neutre. Il redistribue du pouvoir, de l’information et de la charge de travail. Si vous ne l’anticipez pas, les membres de l’organisation le feront à votre place, et pas forcément dans le sens que vous espériez.

Le syndrome du bananier : pourquoi vos transformations technologiques échouent

Vanessa Formicola nomme le piège principal des profils techniques seniors : le « wishful design », la conception rêvée. On dessine l’architecture parfaite, celle que tout le monde utilise en ce moment, sans vérifier si le climat local permet de la faire pousser. Elle décrit trois scénarios d’échec que tout manager reconnaîtra :

• Le bananier du Nord. La technologie est bonne en soi, elle survit, mais ne produit jamais la valeur attendue. Impossible d’attaquer le choix, impossible d’obtenir le retour sur investissement.

• Les palmiers sous la neige. Tout fonctionne au printemps, puis le climat change : changement de direction, cycle budgétaire, nouvelle réglementation. La solution s’effondre alors que le changement était prévisible.

• Le succès incontrôlé. Vous avez été prudent, vous avez fait de petites expérimentations. Ça marche. Puis tout le monde s’en empare, y compris là où les conditions ne sont pas réunies, et l’excès d’une bonne chose devient un problème.

Dans les trois cas, la décision technique était défendable. Ce qui a manqué, c’est la lecture du monde dans lequel on construisait. C’est ce que nous voyons chez Corporate Mavericks dans la plupart des échecs de transformation digitale : on accuse la « résistance au changement » alors que personne n’a regardé le sol.

« Votre travail principal n’est pas de choisir la technologie que vous voulez construire, c’est de construire les conditions pour que n’importe quel choix de technologie, de processus ou d’outil puisse prospérer. »

Vanessa Formicola, QCon London (traduction Corporate Mavericks)

Le sol : les variables organisationnelles qu’on oublie toujours

Dans la métaphore de Formicola, la technologie est le cépage, le produit est le vin, et l’organisation est le sol. On passe des mois à choisir le cépage et cinq minutes à analyser le terrain. Voici les quatre couches de sol qui font ou défont une transformation.

1. Le système de récompense

Bonus, entretiens annuels, grille de carrière, critères de promotion : c’est le levier le plus puissant et le plus ignoré. Formicola raconte que pendant la période d’évaluation annuelle, les gens « deviennent fous » et changent la nature de leur travail pour avoir des choses à démontrer. Si votre système de récompense valorise la performance individuelle, aucun outil collaboratif ne créera de la collaboration. Nous l’avions déjà analysé dans notre article sur la bureaucratie en entreprise : les règles et incitations produisent les comportements, pas les slides.

2. La culture et la confiance

Toute adoption demande un minimum de confiance : accepter de travailler autrement, de montrer ses erreurs, de dépendre d’un nouvel outil. Si les racines de la confiance ne peuvent pas prendre, rien de ce que vous plantez ne tiendra.

3. Le leadership

Une direction divisée, des guerres internes, « une réorganisation toutes les cinq minutes » : vous ne construisez pas sur un terrain stable. Planifier sur le long terme devient impossible et chaque projet devient un pari. Notez aussi que la structure réelle du pouvoir a souvent peu à voir avec l’organigramme. Comprendre comment circulent vraiment l’information et le pouvoir au sein de l’organisation est un préalable à toute décision structurante.

4. La maturité

C’est la phrase la plus utile du talk : la maturité permet la complexité. Les profils techniques surestiment presque toujours la maturité de leur entreprise. On leur demande de « tout refaire à l’état de l’art », et personne n’ose dire que l’organisation n’a pas les fondations pour porter ce niveau de complexité. Une plateforme microservices, un modèle d’équipes autonomes ou un déploiement massif d’agents IA supposent une maturité organisationnelle que beaucoup d’entreprises n’ont pas encore.

Tu en as marre des transformations qui achètent des outils au lieu de changer le terrain ?

Chaque semaine, on décortique une idée qui bouscule le management, avec des actions concrètes à tester.

Le climat : les forces externes que personne ne met dans le plan

Au-delà du sol, il y a le climat, c’est-à-dire tout ce qui vient de l’extérieur et que l’on ne contrôle pas. Formicola en cite plusieurs, et chacune parle à un dirigeant européen en 2026 :

• Les événements mondiaux. La pandémie a vidé les villes et changé du jour au lendemain notre façon de travailler. Les organisations qui avaient construit de la résilience ont pivoté, les autres ont subi.

• La géopolitique. Dans la santé ou la finance, un changement de gouvernement ou de loi peut imposer de revoir un projet en profondeur. La souveraineté numérique, très discutée en Europe, pousse déjà des États et des entreprises à quitter les grands fournisseurs cloud pour les usages sensibles.

• L’éthique et l’acceptabilité. Ce qui est jugé acceptable change selon les pays et les époques. Elle rappelle le stylo « pour femmes » lancé par Bic en 2012, rond et rose, qui a déclenché un tel rejet en ligne que le produit est devenu un cas d’école.

• Les tendances technologiques. L’IA, évidemment, dont tout le monde parle dans chaque réunion et chaque machine à café.

L’approche sociotechnique ne demande pas de prédire l’avenir. Elle demande d’intégrer ces forces comme des variables légitimes de la décision, au même titre que le choix d’une base de données.

Loi de Conway et Team Topologies : l’approche sociotechnique appliquée au logiciel

Dans le monde du logiciel, l’approche sociotechnique a un nom célèbre : la loi de Conway, formulée par Melvin Conway en 1968. Une organisation produit des systèmes dont la structure reproduit sa propre structure de communication. Autrement dit, vos silos se retrouvent dans votre code. Le livre Team Topologies (Matthew Skelton et Manuel Pais, 2019) en a tiré une démarche pratique : concevoir les équipes et l’architecture ensemble, pour que le flux de valeur ne bute pas sur des frontières organisationnelles.

Formicola insiste sur un point que les schémas d’architecture masquent : sur un diagramme, remplacer un service par un autre est un trait de crayon. Dans la réalité, ce service est peut-être du legacy sans tests, maintenu par une seule personne. La complexité du changement sur le papier n’a rien à voir avec celle du terrain. Et si vos domaines métier, vos équipes et votre technologie ne sont pas alignés, la meilleure décision du monde se heurtera à un blocage organisationnel. C’est le même mécanisme que nous décrivions à propos des silos organisationnels.

Ce que l’humain apporte au système (et que l’IA n’apporte pas encore)

À l’heure où chaque entreprise cherche à automatiser tout ce qui peut l’être, Formicola pose une question utile : qu’est-ce qui reste intrinsèquement humain dans un système complexe ? Elle cite cinq capacités, avec la prudence de préciser que l’IA évolue vite :

• Improviser dans un cadre, comme un groupe de jazz qui partage une direction et rebondit sur les idées des autres (le fameux « oui, et »).

• Capter les signaux faibles : sentir en entrant dans une salle qu’une réunion vient de mal tourner, et ajuster sa décision.

• Faire grandir les autres : enseigner, c’est bien plus que transmettre de l’information, c’est adapter, inspirer confiance, servir de modèle.

• Décider dans un système de valeurs souvent implicite, différent des valeurs affichées sur les murs.

• Recadrer la question. Selon elle, dans 99 % des cas en conseil, ce que le client demande n’est pas ce dont il a besoin. Le premier travail est de combler cet écart.

C’est un argument fort pour les managers : dans une approche sociotechnique, faire grandir les personnes n’est pas une responsabilité réservée à la hiérarchie. C’est une compétence centrale de tout leader, technique ou non.

Comment appliquer l’approche sociotechnique dès lundi : 6 leviers concrets

Inutile de lancer un programme de transformation de dix-huit mois. Voici comment passer de jardinier à architecte de la serre, pour reprendre l’image de Formicola.

1. Faites l’autopsie de votre dernière « solution miracle ». C’est la réponse très pragmatique de Formicola à la question « comment mesurer la maturité ? ». Reprenez la dernière technologie ou méthode qui devait tout régler et n’a rien réglé. Cherchez ce qui l’a bloquée. Il y a fort à parier que ce n’était pas la techno, mais un manque de maturité ou un frein culturel. C’est votre meilleur diagnostic.

2. Rendez l’implicite explicite. Les forces sociales sont invisibles parce que personne ne les écrit. Documentez-les : l’effet du processus d’évaluation sur les comportements, les dépendances clés, les zones de pouvoir. Donnez-leur la même dignité qu’un choix d’architecture, et partagez-les largement pour qu’elles deviennent des variables légitimes.

3. Cartographiez le pouvoir réel et les flux d’information. Pas l’organigramme : qui influence vraiment les décisions, par où passe l’information, où sont les goulots.

4. Vérifiez l’alignement domaine, équipes et technologie avant tout projet structurant. Si un sous-domaine métier est partagé entre trois équipes, aucune architecture ne vous sauvera.

5. Mettez ce regard dans les bonnes pièces. Les profils techniques sont rarement invités quand on refond la grille de carrière ou la structure des équipes, alors que ces décisions conditionnent leurs projets. Collectez des preuves (tel projet a déraillé à cause de telle variable non technique) et obtenez un siège au comité de direction élargi.

6. Construisez une petite serre. Plutôt qu’un grand plan, créez localement les conditions favorables, démontrez le résultat, puis étendez. Et donnez un cap clair : quand vous n’êtes pas dans la pièce, les équipes doivent savoir arbitrer seules.

Le point de vue Corporate Mavericks

Soyons honnêtes : la plupart des transformations que nous croisons consistent à acheter un outil, à nommer des rôles et à produire des slides. L’approche sociotechnique n’a rien de nouveau, elle a plus de soixante-dix ans. Ce qui est nouveau, c’est la vitesse à laquelle on plante des technologies (IA générative, agents, plateformes) dans des sols qui n’ont pas bougé depuis vingt ans : mêmes primes individuelles, mêmes circuits de validation, même concentration du pouvoir.

Les entreprises qui réussissent leur passage vers plus d’autonomie sont celles qui travaillent le terreau avant de choisir les graines. Ce n’est pas plus lent. C’est simplement la seule façon de récolter quelque chose.

FAQ : l’approche sociotechnique en questions

C’est une manière de concevoir les organisations qui considère le système social (personnes, relations, rôles, pouvoir) et le système technique (outils, processus, technologies) comme interdépendants. Née au Tavistock Institute avec les travaux d’Eric Trist et Ken Bamforth sur les mines de charbon britanniques, elle vise une optimisation conjointe des deux plutôt que l’optimisation du seul volet technique.C’est un agencement concret, outil, logiciel ou processus, qui embarque des choix sociaux : qui décide, qui accède à quelle information, qui dépend de qui. Les travaux de Madeleine Akrich montrent que chaque objet technique contient un scénario d’usage que les utilisateurs vont adopter, détourner ou rejeter.Le système technique regroupe les équipements, logiciels, méthodes et procédures. Le système social regroupe les personnes, leurs compétences, leurs relations, leurs normes et les incitations qui orientent leurs comportements. L’approche sociotechnique affirme qu’on ne peut pas modifier durablement l’un sans prendre en compte l’autre.La loi de Conway (1968) en est une application directe au logiciel : une organisation conçoit des systèmes qui reproduisent sa structure de communication. Des démarches comme Team Topologies en tirent la conséquence pratique : concevoir les équipes et l’architecture ensemble.L’analyse stratégique de Michel Crozier et Erhard Friedberg est très complémentaire : l’acteur et sa stratégie, le pouvoir, les zones d’incertitude que certains contrôlent, et le système d’action concret. Ces notions aident à comprendre pourquoi une nouvelle technologie redistribue le pouvoir et suscite des résistances.Il n’existe pas de mesure universelle. L’approche la plus pragmatique consiste à analyser ce qui a fait échouer vos initiatives récentes : chaque blocage révèle un manque de maturité ou un frein culturel. Une approche plus formelle consiste à décrire ce à quoi ressemblerait une organisation mature dans votre contexte et à mesurer l’écart.

Travaillez le sol, pas seulement les graines

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management et les organisations, et les transforme en pratiques concrètes.

Product Owner : l’IA va-t-elle supprimer le rôle ?

Marty Cagan vient de l’écrire noir sur blanc : le rôle de product owner dédié est en train de disparaître. Provocation ou lucidité ? Décryptage sans bullshit de ce qui meurt vraiment, de ce qui survit, et de ce que chaque PO peut faire dès lundi.

Le 6 novembre 2026, Marty Cagan (Silicon Valley Product Group, auteur d’Inspired et d’Empowered) a publié la version écrite de sa keynote au Product Leader Summit : AI and the Future of the Product Role. Une phrase y fait l’effet d’une grenade dans la communauté agile : avec l’IA qui automatise et accélère le travail d’ingénierie, et une grande partie du processus de sprint devenue superflue, le rôle de product owner est déjà en train d’être supprimé. Plus loin, il enfonce le clou : selon lui, le rôle de product owner dédié « va se résoudre de lui-même ».

Stefan Wolpers en a fait l’un des titres de sa newsletter Food for Agile Thought #569 (« End of Product Owners »), lue par plus de 35 000 praticiens. Le sujet est partout. Et comme souvent, il est mal compris : beaucoup lisent « Scrum est mort » ou « l’IA remplace les PO ». Ce n’est pas ce que dit Cagan. Ce qu’il décrit est plus dérangeant, parce que ça concerne la façon dont votre organisation fabrique ses produits, pas un intitulé de poste.

Si vous êtes PO, scrum master, manager d’une équipe de développement ou dirigeant qui finance une transformation agile, cet article vous concerne directement.

Le vrai sujet : trois rôles différents cachés derrière un seul mot

L’apport principal de Cagan n’est pas la prédiction, c’est la clarification. Derrière les mots « product manager » et « product owner », il distingue trois rôles qui n’ont presque rien en commun. Et ce qui les sépare, ce n’est pas la méthode agile utilisée, c’est le modèle opérationnel de l’entreprise.

Dans le modèle « projet »

La roadmap liste des fonctionnalités et des projets, chacun étant une solution espérée à un problème rarement explicité. On finance, on staffe, et le succès se mesure au fait d’avoir livré. Deux rôles y cohabitent souvent :

• Le feature team product manager : il coordonne les ressources pour concevoir, construire, tester et livrer la solution déjà décidée. Concrètement, c’est de la gestion de projet. Il écrit de la doc un jour, fait de la recette le lendemain.

• Le product owner au sens où Cagan l’entend : un rôle dans le processus de delivery (Scrum, Kanban, SAFe), qui gère le backlog de livraison et se coordonne avec les développeurs avant, pendant et après les sprints.

Dans le modèle « produit »

La stratégie identifie les problèmes les plus importants à résoudre, et les leaders confient à des équipes un problème associé à un résultat attendu (un outcome). Le succès, c’est l’atteinte de ce résultat, pas la livraison. Le rôle clé y est l’empowered team product manager, responsable de découvrir une solution qui résout réellement le problème.

Point crucial souvent oublié : Cagan précise en note que, quand les équipes utilisent un processus agile, le product manager couvre normalement les responsabilités de product owner. Ce qu’il annonce comme condamné, c’est le product owner dédié, celui qui existe à côté (ou à la place) d’un vrai responsable produit.

Le pronostic de Cagan, rôle par rôle

Product owner dédié

Déjà en voie de disparition : l’IA absorbe une bonne partie du travail de delivery et du processus de sprint.

Feature team PM

Avenir flou : besoin en baisse, une partie de la supervision restera utile, la plupart devront monter en compétences.

Empowered PM

Demande en hausse : quand livrer ne coûte plus rien, savoir quoi construire devient le goulot d’étranglement.

Pourquoi l’IA accélère la fin du product owner « scribe de backlog »

L’argument est mécanique. Les entreprises cherchent à automatiser la delivery avec de l’IA agentique, jusqu’à viser une véritable « usine logicielle » où des agents prennent en charge ce que faisaient développeurs, testeurs, release managers et chefs de projet, sous la supervision des ingénieurs. Or la delivery est faite de workflows bien définis. Et tout ce qui est un workflow bien défini est automatisable.

Regardez honnêtement la semaine type d’un PO dans beaucoup de grandes entreprises IT :

• découper des epics en user stories et rédiger les critères d’acceptation ;

• tenir le backlog à jour et réordonner les priorités demandées par les parties prenantes ;

• préparer le refinement, répondre aux questions de l’équipe de développement sur une fonctionnalité ;

• produire le reporting d’avancement pour le comité de pilotage.

Un agent connecté à Jira fait déjà une bonne partie de ce travail de mise en forme. Stefan Wolpers propose d’ailleurs des exercices pour construire des agents qui préparent le refinement ou génèrent les rapports pour les parties prenantes. Si votre valeur ajoutée tient dans cette liste, la question n’est pas de savoir si votre poste va évoluer, mais quand.

Les fonctionnalités se génèrent de plus en plus vite. Mais construire un produit qui compte, c’est autre chose. Ce qui ne s’automatise pas, selon Cagan, c’est la découverte produit : elle relève moins du workflow que du jugement et du « product sense ». Tester une idée sur des utilisateurs (valeur, utilisabilité), auprès des parties prenantes (viabilité) et avec les ingénieurs (faisabilité), ça reste un métier.

Tu sens que ton rôle glisse vers la saisie de tickets ? Chaque semaine, on décrypte ce qui change vraiment dans le management et le produit, sans jargon ni langue de bois.

Ce que Cagan oublie (ou préfère ne pas dire)

Sur le fond, difficile de lui donner tort. Mais son analyse appelle trois nuances que les managers français devraient garder en tête avant de supprimer des postes.

1. Le product owner du Scrum Guide n’a jamais été un scribe

Dans Scrum, le product owner (souvent abrégé PO) est responsable de maximiser la valeur du produit issue du travail de l’équipe. Il porte l’objectif produit, arbitre, dit non. Sur le papier, c’est bien plus proche de l’empowered product manager de Cagan que du gestionnaire de tickets. Ce qui meurt, ce n’est donc pas le rôle de product owner tel que pensé par Scrum, c’est sa version dégradée : le « proxy PO » sans pouvoir de décision, nommé pour faire tourner la machine pendant que les vraies décisions se prennent ailleurs.

2. Le problème n’est pas le rôle, c’est le modèle projet

Cagan le reconnaît lui-même : beaucoup d’entreprises, sans doute la majorité, n’abandonneront jamais le modèle projet, à cause de leur besoin de prévisibilité. Résultat probable : on va retirer les product owners, garder la roadmap de fonctionnalités imposée par le haut, et demander aux ingénieurs de piloter des agents pour livrer plus vite des choses dont personne n’a vérifié l’utilité. Ce n’est pas une transformation, c’est de l’accélération de gaspillage.

3. Livrer plus vite n’a jamais été le problème des utilisateurs

Dans la même édition de Food for Agile Thought, Pavel Samsonov rappelle qu’on noie déjà les utilisateurs sous des mises à jour et des tableaux de bord que personne n’a demandés, et que des résumés générés par l’IA ne les sauveront pas : l’attention reste rare. Si l’IA supprime le goulot de la livraison, il faut quelqu’un pour dire non. C’est exactement le travail que beaucoup de PO n’ont jamais eu le droit de faire.

« Les product managers qui ont toujours vu leur rôle comme « mon job principal, c’est d’exécuter » ont beaucoup plus de mal à se faire embaucher dans les meilleures entreprises que ceux qui le voient comme « mon job principal, c’est de faire réussir le produit ». »Shreyas Doshi, cité par Marty Cagan (traduction Corporate Mavericks)

Product owner ou product manager : quelle différence, concrètement ?

C’est la question que tout le monde se pose, et la réponse dépend de votre organisation plus que des définitions. Un test simple : regardez qui décide du problème à résoudre et comment on mesure le succès.

• Si un comité vous transmet une liste de fonctionnalités et que votre succès se mesure à leur livraison dans les délais, vous faites de la gestion de projet, quel que soit le titre sur votre badge.

• Si on vous confie un problème client avec un résultat business à atteindre, et que vous pouvez renoncer à une fonctionnalité qui ne sert à rien, vous faites du produit.

Le rôle du product owner, dans beaucoup d’organisations, c’est la responsabilité sans l’autorité. Un product manager « empowered » a les deux. Le titre importe peu : c’est ce glissement de la livraison vers la découverte qui va séparer ceux qui progressent de ceux qui seront remplacés par un agent.

Product owner en 2026 : 5 leviers pour rester indispensable

Cagan dit avoir encouragé les PO à monter en compétences « aussi vite que possible ». Voici ce que ça veut dire concrètement, sans attendre que l’entreprise change de modèle.

1. Faire l’inventaire honnête de votre semaine

Listez vos tâches et classez-les : workflow répétable (rédaction de stories, reporting, mise à jour du backlog) ou jugement (arbitrer, dire non, comprendre un client). Déléguez la première colonne à l’IA, volontairement, avant qu’on le fasse à votre place. Le temps libéré doit aller vers la seconde.

2. Passer de la livraison à la découverte

Parlez à des utilisateurs chaque semaine. Prototypez pour apprendre (« build to learn ») avant de construire pour livrer (« build to earn »). Avec l’IA, un prototype coûte quelques heures : il n’y a plus d’excuse pour développer une fonctionnalité sans l’avoir testée.

3. Réclamer des résultats, pas des listes

À chaque demande d’une partie prenante, posez la question : quel problème, quel indicateur doit bouger ? Transformer une demande de fonctionnalité en objectif mesurable est la compétence la plus rare et la plus protectrice du métier.

4. Muscler le business et le domaine

Selon Cagan, le product manager doit connaître en profondeur le marché, le client et les dimensions de la viabilité : ventes, marketing, finance, juridique, conformité, sécurité. Un développeur assisté par l’IA couvre la faisabilité. Personne ne couvre la valeur et la viabilité si vous ne le faites pas.

5. Devenir le gardien des évaluations IA

Pour les produits probabilistes (ceux qui embarquent de l’IA), Cagan place le product manager au centre du processus d’évaluation : décider quand une réponse est acceptable ou non. C’est un terrain neuf, où le PO qui connaît finement les usages a une vraie longueur d’avance.

Et pour les managers et dirigeants ?

Supprimer les PO pour économiser une ligne de budget pendant que l’IA accélère la delivery, c’est la tentation du moment. C’est aussi la meilleure façon de produire plus vite des choses inutiles. La vraie question à poser en comité de direction n’est pas « combien de PO peut-on retirer ? » mais « qui, chez nous, a le pouvoir et le temps de décider quoi construire ? ».

Si la réponse est « un comité qui valide une roadmap annuelle », l’IA ne va rien sauver. Elle va juste rendre visible, plus vite, que votre organisation pilote des sorties (output) au lieu de résultats (outcome). Donnez à vos PO de vrais problèmes à résoudre, l’autorité pour arbitrer et des indicateurs de résultat : vous obtiendrez des product managers. Gardez-les comme courroies de transmission : l’IA les remplacera, et vous n’aurez rien gagné.

Faut-il encore devenir product owner ?

Oui, à condition de viser le bon métier. Pour réussir, un product owner doit désormais savoir parler de résultats autant que de livraison. La certification Scrum ou SAFe reste une porte d’entrée utile pour comprendre le cadre, mais elle ne fera plus la différence sur un CV. Ce qui fera la différence : des preuves que vous savez découvrir un problème, tester une solution et faire bouger un indicateur. Pour devenir product owner aujourd’hui, investissez autant dans les entretiens utilisateurs, la lecture de données et la compréhension d’un compte de résultat que dans la maîtrise de Jira.

Côté marché, les offres d’emploi intitulées « product owner » ne vont pas disparaître du jour au lendemain, notamment dans les grands groupes en modèle projet. Mais l’écart de salaire et de trajectoire entre le PO « exécutant » et le responsable produit orienté résultat va se creuser. C’est précisément le message de Doshi.

Questions fréquentes sur le product owner et l’IA

Selon Marty Cagan, le product owner dédié, centré sur la gestion du backlog de livraison, est déjà en voie de disparition dans les entreprises où l’IA automatise la delivery. En revanche, les responsabilités de product owner (maximiser la valeur du produit, arbitrer les priorités) ne disparaissent pas : elles sont absorbées par des product managers orientés découverte et résultats.Dans Scrum, le product owner est responsable de maximiser la valeur du produit issue du travail de l’équipe. Il porte la vision du produit et l’objectif produit, ordonne le Product Backlog, arbitre les priorités avec les parties prenantes et travaille en étroite collaboration avec l’équipe de développement et le scrum master.Dans beaucoup d’entreprises, le product owner gère la delivery (backlog, user stories, sprints) tandis que le product manager porte la stratégie, la découverte et les résultats business. Marty Cagan distingue trois rôles : le product owner de delivery, le feature team product manager (proche du chef de projet) et l’empowered product manager, responsable d’un résultat.La découverte produit (entretiens utilisateurs, prototypage, tests de valeur et d’utilisabilité), la connaissance du business et du domaine, la capacité à transformer une demande de fonctionnalité en objectif mesurable, l’usage de l’IA pour automatiser les tâches répétitives et, pour les produits intégrant de l’IA, la conduite des évaluations de qualité.Le salaire d’un product owner varie fortement selon l’entreprise, le secteur IT et l’expérience. La tendance décrite par Cagan et Shreyas Doshi est claire : les profils orientés résultat et découverte sont les plus recherchés, ceux centrés sur l’exécution ont plus de mal à se faire embaucher.Pas sans changer le modèle opérationnel. Retirer le product owner en gardant une roadmap de fonctionnalités imposée revient à livrer plus vite des choses non validées. Le bon mouvement consiste à confier aux équipes des problèmes et des résultats à atteindre, et à donner au responsable produit l’autorité d’arbitrer.

Le jugement ne s’automatise pas

Chaque semaine, la newsletter Corporate Mavericks décrypte les idées qui bousculent le management et le produit, et les transforme en pratiques concrètes.

Sens au travail : l’IA devait prendre les corvées, elle prend aussi ce que vous aimiez

Une nouvelle étude du Teamwork Lab d’Atlassian sur 1 013 salariés casse la promesse préférée des éditeurs d’IA. Ce que ça révèle sur le sens au travail, et ce que les managers doivent décider avant que l’efficacité ne décide à leur place.

Depuis trois ans, le discours est rodé : laissez l’IA s’occuper des tâches pénibles, et vos équipes auront enfin du temps pour le travail qui compte. Le reporting du lundi, les comptes rendus, le tri des mails, tout ça part à la machine. Il reste l’analyse, la création, la relation. Bref, le sens au travail serait protégé, voire renforcé. Sauf que les salariés qui utilisent l’IA au quotidien racontent une autre histoire.

Le Teamwork Lab d’Atlassian a interrogé 1 013 travailleurs du savoir américains entre fin septembre et début octobre 2026 (lire l’étude originale, en anglais). Résultat : parmi les utilisateurs d’IA, 82 % disent que l’IA a pris en charge au moins une partie du travail qu’ils n’aiment pas. Et exactement la même proportion, 82 %, dit qu’elle a aussi pris une partie du travail qu’ils aiment. Plus inquiétant : 10 % affirment que l’IA a absorbé tout le travail qu’ils apprécient, contre 3 % seulement pour le travail qu’ils détestent.

Personne n’a conçu ça volontairement. C’est simplement ce qui arrive quand personne ne décide ce qu’il faut protéger. Et c’est exactement là que se joue la prochaine bataille de l’engagement dans l’entreprise.

Qu’est-ce que le sens au travail, concrètement ?

Avant de parler d’IA, posons les bases. Le sens du travail n’est pas un slogan RH ni une « raison d’être » affichée dans le hall d’accueil. Les chercheurs Thomas Coutrot et Coralie Perez, dans Redonner du sens au travail (Seuil, 2022), le décomposent en trois dimensions très concrètes :

• L’utilité sociale : avoir le sentiment que son travail sert à quelque chose, pour les clients, les collègues ou la société. Se sentir utile.

• La cohérence éthique : pouvoir faire son travail en accord avec ses valeurs, sans devoir bâcler ou tricher pour tenir les objectifs.

• La capacité de développement : apprendre, progresser, exercer son jugement, disposer d’une vraie marge de manœuvre.

On peut aussi passer par l’ikigai, ce schéma japonais qui croise ce que vous aimez, ce en quoi vous êtes doué, ce dont le monde a besoin et ce pour quoi on vous paie. Le modèle est plus grand public, mais il dit la même chose : le sens est très personnel, propre à chaque individu, et il naît en grande partie de l’activité elle-même, pas des discours qui l’entourent.

C’est là que l’étude Atlassian fait mal. Si l’IA absorbe précisément les tâches où vous exercez votre jugement et où vous apprenez, elle ne vous libère pas : elle grignote la troisième dimension du sens. La quête de sens ne disparaît pas, elle se retrouve juste sans terrain de jeu.

Plus l’IA est installée, plus elle mange la meilleure part

Le détail le plus parlant de l’étude concerne l’intensité d’usage. Les utilisateurs occasionnels, ceux qui sortent l’IA comme une rustine pour une tâche ponctuelle, lui confient surtout ce qu’ils n’aiment pas : 31 % disent qu’elle gère une part modérée ou plus du travail qu’ils détestent, contre 24 % pour le travail qu’ils apprécient.

Dès que l’IA devient la norme dans les flux de travail de l’équipe, la courbe s’inverse :

58 %

gèrent via l’IA une part notable du travail qu’ils n’aiment pas

71 %

gèrent via l’IA une part notable du travail qu’ils aiment

Autrement dit : plus l’organisation du travail intègre l’IA, plus elle déborde des corvées vers le cœur du métier. Ce n’est pas un bug de l’outil, c’est une conséquence logique. Les tâches intéressantes sont souvent aussi celles où l’IA est la plus impressionnante (rédiger, analyser, synthétiser, concevoir). Si le seul critère est la vitesse, elles partent en premier.

Tu veux plus d’analyses comme celle-ci, sans jargon ni langue de bois ?

Les dirigeants ont fait un échange que leurs équipes n’ont pas signé

Deuxième enseignement, et pas le moins piquant : plus on monte dans la hiérarchie, plus l’IA a absorbé le travail qu’on aime. 60 % des dirigeants (niveau directeur et au-dessus) disent que l’IA gère une part modérée ou plus du travail qu’ils apprécient, contre 42 % des managers et 36 % des contributeurs individuels. Les dirigeants sont aussi deux fois plus souvent des utilisateurs intensifs que les managers.

Le problème n’est pas qu’un directeur délègue sa note stratégique à un modèle de langage. Le problème, c’est que ce sont ces mêmes personnes qui redessinent le travail de tout le monde. Molly Sands, qui dirige le Teamwork Lab, le résume ainsi (traduction de notre part) : « Les dirigeants ont délégué plus de travail qu’ils aiment que quiconque dans l’organisation, et ce sont eux qui fixent les normes pour tous les autres. Ce qui ressemble à un échange équitable pour un directeur ne l’est pas forcément pour quelqu’un en début de carrière, qui construit encore les compétences que ce travail développe. »

On retrouve ici un sujet qu’on a déjà creusé : quand l’IA mange le travail formateur, c’est toute l’échelle de progression qui perd ses barreaux (voir notre analyse sur le développeur junior face à l’IA). Un manager qui a vingt ans de métier peut se passer de rédiger un premier jet. Un collaborateur de deux ans d’expérience, non : c’est précisément en écrivant des premiers jets ratés qu’il apprend.

Même décalage sur l’expertise : 48 % des dirigeants de niveau VP et plus estiment que l’IA permet à des non experts de prendre des décisions de spécialiste. Sous ce niveau, ils ne sont que 22 % à le penser. Ceux qui sont loin du terrain surestiment ce que l’outil sait vraiment faire.

Expertise : l’IA ouvre la porte, elle ne donne pas les clés

On entend partout que l’IA va transformer tout le monde en généraliste. Les salariés qui l’utilisent n’y croient pas. Les chiffres :

• 95 % des utilisateurs disent que l’IA a rendu au moins une tâche experte plus accessible aux non spécialistes (analyser des informations, relire un travail, produire un premier jet : autour de 60 % pour chacune).

• Mais seulement 41 % estiment qu’elle aide les non experts à contribuer de façon significative aux livrables finaux, et 28 % qu’elle leur permet de prendre des décisions qui exigeaient un spécialiste.

• 54 % pensent au contraire que l’IA va créer davantage de spécialistes, parce que le jugement expert comptera plus pour guider le travail et repérer les erreurs. Chez les gros utilisateurs, ce chiffre monte à 60 % (contre 50 % chez les utilisateurs plus légers).

Le paradoxe est total : les plus convaincus que l’expertise compte sont aussi ceux qui délèguent le plus à l’IA le travail qui fabrique cette expertise. Si on ne fait rien, on scie la branche sur laquelle repose le jugement de demain.

« Vu de l’extérieur, il est facile pour un dirigeant de supposer que l’IA permet à n’importe qui de faire le travail d’un expert. Mais les personnes qui font le travail savent quelles parties demandent un vrai jugement. Avant de décider ce que vous confiez à l’IA, demandez leur. »Molly Sands, responsable du Teamwork Lab d’Atlassian (traduction Corporate Mavericks)

Qui décide ? Garder le jugement humain là où l’enjeu est fort

Bonne nouvelle : les salariés ne rejettent pas l’IA. Dans tous les scénarios testés, la majorité veut qu’elle joue un rôle, y compris environ 9 personnes sur 10 pour analyser des données, enchaîner des actions routinières ou même aborder un problème inédit. Ce qui change, c’est qui mène.

• Pour le travail à fort volume, environ deux tiers acceptent que l’IA prenne la main, avec ou sans contrôle humain : 68 % pour passer en revue de grands volumes de données, 66 % pour les actions routinières.

• Dès qu’il faut du jugement, ça bascule. Les humains doivent mener pour les problèmes nouveaux ou complexes (58 %), pour décider des priorités (66 %), pour les livrables qui demandent une expertise pointue (67 %) et pour les décisions à haut risque (78 %).

• Seulement 3 % laisseraient l’IA prendre seule une décision à haut risque. Même pour les actions de routine, ils ne sont que 18 %.

Ce qui frappe, c’est la maturité de ces réponses. Les équipes savent instinctivement faire la différence entre exécuter et décider. Ce qui manque, ce n’est pas leur discernement, c’est un cadre explicite dans l’organisation pour le faire respecter.

Donner du sens au travail quand l’IA s’invite : 5 leviers pour les managers

L’IA continuera de prendre plus de place. La vraie question est de savoir si l’équipe choisit ce qu’elle lui confie, ou si l’efficacité décide par défaut. Voici les leviers que nous recommandons aux managers que nous accompagnons.

1. Cartographier les tâches avec l’équipe, pas à sa place

Organisez un atelier d’une heure. Chaque personne liste ses tâches et les classe en trois colonnes : « je délègue volontiers à l’IA », « je veux la garder », « je veux la faire avec l’IA mais garder la main ». Vous découvrirez que ce qui ressemble à une corvée pour vous est parfois la partie préférée de quelqu’un d’autre. C’est la recommandation centrale de l’étude : demandez aux personnes qui font le travail.

2. Ajouter deux critères à chaque décision d’automatisation

Aujourd’hui, on automatise sur deux critères : vitesse et qualité. Ajoutez-en deux autres : « est-ce que cette tâche entretient l’engagement de quelqu’un ? » et « est-ce qu’elle construit une compétence dont l’équipe aura besoin ? ». Si la réponse est oui, confier ce travail à l’IA peut rester possible, mais ça doit être un choix délibéré, pas un effet de bord.

3. Rendre explicite qui mène selon l’enjeu

L’IA mène sur le volume, avec contrôle humain. Les humains mènent sur les problèmes nouveaux, les priorités, l’expertise et les décisions à risque. Écrivez cette règle et faites-en une norme d’équipe. Le Delegation Poker de Management 3.0, avec ses sept niveaux de délégation, se transpose très bien : jouez-le en ajoutant l’IA comme acteur autour de la table.

4. Protéger le travail qui forme le jugement

Une partie du travail que l’IA sait faire est aussi la façon dont les gens deviennent bons. Gardez-en assez pour les profils en début de carrière : premiers jets, analyses de cas, revues de code ou de dossiers. Moins rapide à court terme, indispensable si vous voulez encore des experts dans trois ans.

5. Revisiter la répartition régulièrement

Les outils évoluent tous les trimestres, la répartition aussi. Consacrez un point de rétrospective par mois à une seule question : « qu’est-ce que l’IA a pris ce mois-ci qu’on regrette ? ». La transparence dans les décisions fait partie du sens : une équipe qui comprend pourquoi une tâche part à la machine le vit très différemment d’une équipe qui le découvre.

Perte de sens : le vrai coût caché de l’IA pour l’engagement des salariés

On mesure le ROI de l’IA en heures gagnées. Personne ne mesure ce qu’elle coûte en engagement au travail. Pourtant, le mécanisme est connu : la théorie de l’autodétermination (Deci et Ryan) montre que la motivation durable repose sur l’autonomie, le sentiment de compétence et le lien aux autres. Retirez à quelqu’un les tâches où il se sent compétent, et vous attaquez directement l’un de ces piliers.

Le salarié ne démissionne pas le lendemain. Il décroche doucement. Il fait le contrôle qualité des sorties de l’IA, valide, corrige, et se demande à quoi il sert. C’est la version 2026 de la perte de sens : pas un travail absurde, mais un travail vidé de ce qui le rendait intéressant. Avec à la clé des effets sur le bien-être au travail et la santé mentale que les DRH commencent à peine à voir remonter.

Chez Corporate Mavericks, on a une position simple : le sens au travail ne se décrète pas dans une charte, il se protège dans l’organisation du travail, tâche par tâche. Les entreprises qui s’en sortiront ne sont pas celles qui adopteront l’IA le plus vite, mais celles qui sauront dire « ça, on le garde ». Et qui laisseront leurs collaborateurs participer à ce choix.

Questions fréquentes sur le sens au travail et l’IA

Le sens au travail désigne le sentiment que son activité professionnelle a une valeur. Les chercheurs Thomas Coutrot et Coralie Perez le décrivent selon trois dimensions : l’utilité sociale (se sentir utile), la cohérence éthique (travailler en accord avec ses valeurs) et la capacité de développement (apprendre, exercer son jugement, disposer d’autonomie).Elle peut le faire si personne ne choisit ce qu’elle prend en charge. Selon le Teamwork Lab d’Atlassian, 82 % des utilisateurs d’IA disent qu’elle a absorbé une partie du travail qu’ils aiment, autant que du travail qu’ils n’aiment pas. Et plus l’IA est intégrée dans l’équipe, plus elle déborde vers les tâches appréciées.Les principaux leviers sont l’autonomie et la marge de manœuvre, la visibilité sur l’utilité du travail, la cohérence entre les objectifs et les valeurs, et la possibilité d’apprendre. Face à l’IA, il faut y ajouter un levier nouveau : décider avec l’équipe quelles tâches restent humaines.La théorie de l’autodétermination identifie trois besoins fondamentaux : l’autonomie, le sentiment de compétence et le lien social. L’IA fragilise surtout le sentiment de compétence quand elle prend en charge les tâches où les salariés exercent leur expertise, et l’autonomie quand son usage est imposé sans concertation.En partant du terrain : cartographier les tâches avec l’équipe, intégrer l’engagement et l’apprentissage dans chaque décision d’automatisation, rendre explicite qui décide selon l’enjeu, protéger le travail formateur des juniors et revoir la répartition régulièrement en rétrospective.Pas forcément la limiter, mais la piloter. Les salariés veulent l’IA dans presque tous les scénarios ; ils veulent surtout garder la main sur les décisions importantes (78 % pour les décisions à haut risque). Le bien-être au travail dépend moins du volume d’IA que de la façon dont son rôle est négocié.

Le sens ne se délègue pas à une machine

Chaque semaine, la newsletter Corporate Mavericks décrypte les études qui comptent et les transforme en pratiques concrètes pour manager autrement.

La lecture paresseuse tient en une phrase : « un ingénieur a fait une erreur ». C'est celle que font la plupart des organisations après un incident, un lancement raté ou un client perdu. Elle soulage, elle désigne, et elle ne change rien. Amy Edmondson raconte avoir vu pendant vingt ans des managers sincères consacrer de nombreuses heures à des retours d'expérience et des post-mortems qui ne produisaient aucun changement réel, parce qu'ils pensaient l'échec de la mauvaise façon (Harvard Business Review, 2011).

• Pourquoi vos post-mortems ne changent rien : les trois pièges qui transforment l'analyse en procès, en usine à tickets ou en document mort.

• Ce que font Google, Etsy et Atlassian, d'après leurs propres publications, et ce que révèle le cas GitLab lu jusqu'au bout.

• Le livrable : un kit complet de revue post-incident sans coupable, utilisable tel quel : critères de déclenchement, préparation, canevas d'atelier de 75 minutes, banque de questions, modèle de document, grille de qualité des actions et baromètre de culture en six questions.

• Un plan d'action à 7, 30 et 90 jours pour installer la pratique sans en faire une usine à gaz.

La suite est réservée aux membres de The Mavericks Club. Si vos équipes vivent des incidents, des livraisons ratées ou des projets qui déraillent, ce kit est fait pour vous.

Read more

Communication de crise : quand un PDG tombe pour avoir parlé la mauvaise langue

Le message était juste, le fond irréprochable, et pourtant tout s’est effondré en quelques jours. Ce que l’affaire Air Canada révèle sur la communication de crise, et pourquoi le « comment » pèse autant que le « quoi ».

Mars 2026. Un avion d’Air Canada percute un véhicule de pompiers à l’atterrissage sur l’aéroport LaGuardia de New York. Les deux pilotes meurent, de nombreux passagers sont blessés. Le PDG, Michael Rousseau, publie rapidement un message de condoléances qui détaille la réponse de la compagnie. Sur le fond, rien à redire : c’est clair, opérationnel, sous-titré en français. Sur la forme, c’est une catastrophe. Hormis un « bonjour » et un « merci », il parle entièrement en anglais. Quelques jours plus tard, il annonce sa démission. Voilà ce qui arrive quand une communication de crise oublie à qui elle s’adresse.

Air Canada a son siège au Québec, une province bilingue où la langue française porte une charge culturelle et identitaire forte. Pour une partie des Québécois touchés, y compris la famille de l’un des pilotes, ce discours en anglais a sonné comme du mépris. Ce n’est pas le contenu qu’on lui a reproché : c’est la manière. Deux chercheuses, S. Amy Sommer (McMaster University) et Christine M. Pearson (Thunderbird School of Global Management), viennent de décortiquer ce cas dans la MIT Sloan Management Review (lire l’article original, en anglais).

Leur constat dépasse largement l’aérien. Les chaînes d’approvisionnement traversent les continents, les comités de direction vivent sur trois fuseaux horaires, et une crise en entreprise traverse désormais autant de cultures que de frontières. Chez Corporate Mavericks, on y voit surtout un sujet de leadership : la crise ne fabrique pas votre culture managériale, elle la met à nu. Voici ce qu’il faut comprendre, et ce que vous pouvez préparer dès maintenant.

Qu’est-ce que la communication de crise, vraiment ?

Dans les manuels, la communication de crise consiste à informer les parties prenantes (salariés, clients, victimes, médias, autorités, actionnaires) quand un événement grave menace les personnes, l’activité ou la réputation d’une organisation. Elle vise à limiter les dommages, à couper court aux spéculations et aux fausses informations, et à préserver la confiance du public. On pense spontanément au communiqué de presse, aux relations avec les médias et aux éléments de langage validés par le juridique.

C’est nécessaire, mais très insuffisant. Une communication de crise efficace n’est pas un exercice de rédaction, c’est un acte de leadership en situation de crise. Les gens ne retiennent pas vos phrases, ils retiennent ce que votre attitude dit de vous : est-ce que ce dirigeant est là, est-ce qu’il nous comprend, est-ce qu’il nous respecte ? Le message de Michael Rousseau cochait toutes les cases de la check-list classique. Il a échoué sur la seule question qui comptait pour les personnes touchées : « est-ce qu’il nous parle à nous ? »

Dans un contexte interculturel, l’efficacité ne dépend pas seulement de ce qui est communiqué, mais de la manière dont c’est transmis.S. Amy Sommer et Christine M. Pearson, MIT Sloan Management Review (traduit de l’anglais)

Lac-Mégantic 2013 : le précédent que personne n’a retenu

Le plus troublant, c’est que l’histoire s’était déjà écrite. En 2013, un train fou appartenant à une compagnie ferroviaire américaine explose dans la petite ville de Lac-Mégantic, au Québec. Le centre-ville est détruit, 47 personnes meurent. Cinq jours plus tard, le président de la compagnie, Edward Burkhardt, arrive de Chicago et s’exprime, lui aussi, uniquement en anglais devant une communauté francophone encore sous le choc.

Lui pensait faire preuve de transparence en défendant les décisions de son entreprise. La population endeuillée y a vu de l’arrogance et de la distance. Pour elle, le leadership face à la crise voulait dire présence, compassion, humilité et reconnaissance de la perte. Pas un argumentaire. Les habitants ont surnommé l’accident « le train d’enfer », et la séquence est restée comme un cas d’école de mauvaise lecture du contexte émotionnel et culturel.

Treize ans d’écart, deux dirigeants, la même erreur. Ce qui montre une chose : les organisations apprennent très mal des crises des autres, parce qu’elles les lisent comme des fautes individuelles (« il a été maladroit ») plutôt que comme des angles morts systémiques. Le même biais qui fait que, dans vos réunions, tout le monde hoche la tête au lieu de signaler le problème (on en parlait dans notre article sur la pensée de groupe).

Les 3 points de pression d’une crise qui traverse les cultures

Sommer et Pearson identifient trois zones de friction qui compliquent la gestion de crise dès qu’elle franchit une frontière culturelle. Leur message clé : ces trois facteurs se travaillent à froid, avant l’incident, pas pendant.

1. Le style de communication

Direct ou indirect, factuel ou émotionnel, langue officielle ou langue du cœur. Une prise de parole parfaitement rationnelle peut paraître froide, voire insultante, si le public attend d’abord de l’empathie. La langue elle-même est un message.

2. La déférence hiérarchique

Dans certaines cultures, on ne contredit pas le chef, même quand on voit le mur arriver. Les mauvaises nouvelles remontent lentement, filtrées, adoucies. Résultat : la direction découvre l’ampleur de la crise trop tard, et les équipes locales attendent des ordres au lieu d’agir.

3. Le timing

Quand parler, et qui doit parler en premier ? Trop tôt, on donne l’impression de défendre l’entreprise avant les victimes. Trop tard (cinq jours à Lac-Mégantic), on donne l’impression de s’en moquer. Les fuseaux horaires et les circuits de validation aggravent tout.

Remarquez qu’aucun de ces trois points ne se règle avec un meilleur communiqué de presse. Ils relèvent de la préparation, de l’organisation et de la culture managériale. Autrement dit : de votre travail de leader, bien avant le jour J.

Tu préfères préparer la tempête plutôt que la subir ?

Chaque semaine, on décortique ce qui marche vraiment en management, en organisation et en transformation. Zéro jargon, zéro bullshit.

Comment faire une bonne communication de crise ? Les 4 phases

On découpe classiquement une crise en quatre temps. Pour chacun, voici ce que l’affaire Air Canada nous oblige à ajouter.

1. Avant : la préparation

C’est là que tout se joue. Un plan de communication de crise sérieux contient une cartographie des parties prenantes et des publics, des scénarios crédibles, une cellule de crise nommée (avec des suppléants), des canaux de communication testés et des messages clés préparés. Ajoutez-y une question que presque personne ne pose : dans quelle langue, avec quel ton et par quelle voix chaque public a-t-il besoin d’être adressé ? Si votre porte-parole naturel ne parle pas la langue d’une communauté clé, prévoyez dès maintenant qui le fera.

2. Le déclenchement : les premières heures

Dès les premiers instants, le vide se remplit tout seul, avec des rumeurs. L’objectif n’est pas d’avoir toutes les réponses, mais de montrer que l’organisation est présente, qu’elle prend la mesure du drame et qu’elle reviendra vers les gens à une heure précise. Reconnaître la souffrance avant d’expliquer les procédures : l’ordre compte.

3. Pendant : tenir dans la durée

Une communication transparente, régulière et cohérente entre la communication interne et la communication externe. Dire ce qu’on sait, ce qu’on ne sait pas encore, et les prochaines étapes (enquêtes en cours, aide aux personnes touchées). C’est aussi le moment où la hiérarchie doit écouter le terrain plus que jamais : les équipes locales savent ce qui va être mal reçu.

4. Après : apprendre pour de vrai

Un retour d’expérience honnête, sans chercher de coupable, qui interroge les angles morts culturels autant que les failles opérationnelles. Et, idéalement, l’étude des crises des autres. Lac-Mégantic était documenté depuis 2013. Une crise bien gérée commence souvent par une crise mal gérée chez quelqu’un d’autre, à condition de la regarder en face.

Communication interne : vos équipes vivent la crise avant vos clients

On réduit souvent la communication de crise à l’image publique. Erreur. Les premiers publics d’une crise, ce sont vos salariés : ils sont en première ligne face aux clients, ils lisent les réseaux sociaux, ils parlent à leurs proches. S’ils apprennent la nouvelle par la presse, vous avez déjà perdu une partie de leur confiance. Et des collaborateurs qui ne comprennent pas la position de l’entreprise deviennent, malgré eux, une source de spéculations.

Le deuxième point de pression identifié par les chercheuses, la déférence à la hiérarchie, est ici décisif. Dans une organisation où l’on n’ose pas dire au patron que sa vidéo va mal passer, personne ne lui dira « parlez en français ». La question n’est donc pas seulement « qui valide le message ? » mais « qui a le droit, et le courage, de dire non au dirigeant avant que le message parte ? » Si la réponse est « personne », vous n’avez pas de cellule de crise : vous avez une chambre d’écho.

C’est exactement le même mécanisme que dans les équipes qui évitent les désaccords au quotidien (voir notre article sur les conflits en équipe). Une organisation qui étouffe la contradiction en temps normal ne la retrouvera pas par miracle le jour où tout brûle.

La checklist anti-bullshit pour votre stratégie de communication de crise

À faire ce trimestre, pas le jour de la catastrophe :

• Cartographiez vos publics par culture, pas seulement par catégorie (clients, salariés, élus). Langue, attentes émotionnelles, rapport à l’autorité.

• Nommez plusieurs porte-parole, dont au moins un capable de s’adresser à chaque communauté clé dans sa langue et avec ses codes.

• Désignez un « contradicteur officiel » dans la cellule de crise, chargé de relire chaque prise de parole avec les yeux des personnes touchées.

• Raccourcissez les circuits de validation : une stratégie qui exige six signatures sur trois fuseaux horaires sera toujours en retard.

• Préparez l’ordre des messages : d’abord les personnes, ensuite les faits, enfin l’organisation. Jamais l’inverse.

• Entraînez-vous avec des simulations réalistes qui incluent un piège culturel, pas seulement un incident technique.

• Faites remonter les mauvaises nouvelles sans punition : c’est la condition pour bien gérer une crise qui démarre loin du siège.

• Étudiez les crises des autres en équipe de direction, au moins une fois par an. Air Canada fera un excellent premier cas.

Une agence de communication peut vous aider sur les outils et les relations avec les médias. Elle ne peut pas remplacer une culture où les gens osent parler vrai.

Le vrai sujet : la crise révèle votre culture, elle ne la crée pas

On aimerait croire que la gestion de crise est une compétence technique qu’on active le moment venu, comme un extincteur. L’affaire Air Canada montre l’inverse. Un dirigeant entouré de gens qui lui auraient dit « ici, on parle français, et on commence par les familles » n’aurait probablement pas eu à démissionner. Son échec n’est pas celui d’un texte, c’est celui d’un système qui ne l’a pas protégé de son angle mort.

La bonne nouvelle, c’est que tout ce qui rend une organisation solide en temps de crise se construit en temps calme : la confiance entre les équipes, la liberté de contredire, la connaissance fine de vos publics, la capacité à décider vite près du terrain. Ce sont exactement les sujets que l’on travaille avec les managers qui veulent sortir du pilotage par le contrôle. La prochaine crise arrivera. La seule question, c’est de savoir si votre culture sera prête à parler la bonne langue.

Questions fréquentes sur la communication de crise

On distingue en général la préparation (plan, cellule de crise, messages clés, porte-parole), le déclenchement (les premières heures, où il faut montrer sa présence et son empathie), la gestion pendant la crise (informations régulières, transparentes et cohérentes) et l’après-crise (retour d’expérience et reconstruction de la confiance).C’est l’ensemble des actions de communication qu’une organisation mène pour informer ses parties prenantes, limiter les dommages et préserver sa réputation lorsqu’un événement grave survient. Elle couvre aussi bien la communication externe (médias, clients, autorités) que la communication interne (salariés, managers).On cite souvent la communication verbale, non verbale, écrite et visuelle. En situation de crise, les quatre comptent : les mots, mais aussi le ton, la présence physique sur place, la langue choisie et les images diffusées. L’affaire Air Canada montre qu’un message écrit impeccable ne compense pas un signal non verbal mal perçu.Préparer à froid un plan de communication de crise, réagir vite en reconnaissant d’abord l’impact humain, dire ce que l’on sait et ce que l’on ignore, parler à chaque public dans sa langue et avec ses codes, aligner communication interne et externe, puis tirer de vraies leçons une fois la crise passée.La cellule de crise réunit les décideurs et experts nécessaires (direction, communication, juridique, opérations, RH) pour analyser la situation, décider vite et coordonner les prises de parole. Elle n’est efficace que si chacun peut y exprimer un désaccord, y compris face au dirigeant.Une agence spécialisée apporte de l’expérience, des outils de veille et un réseau dans les médias, ce qui est utile pour une crise d’ampleur. Mais elle ne connaît ni vos équipes ni vos publics aussi bien que vous : la préparation culturelle et managériale reste votre responsabilité.

Une culture solide se construit avant la tempête

Rejoins la newsletter Corporate Mavericks : chaque semaine, des idées concrètes pour manager autrement, sans langue de bois.

Développeur junior et IA : l’échelle de carrière a perdu ses barreaux

L’intelligence artificielle fait aujourd’hui le travail qui formait hier les débutants. Résultat : on recrute moins de juniors, ceux qu’on recrute apprennent moins, et personne ne se demande qui supervisera les agents dans dix ans.

Lundi matin, entretien d’embauche pour un poste de développeur junior. Le candidat présente un portfolio impressionnant : une application full stack, une API en Python, un petit projet de machine learning. Le recruteur pose une question simple : « Pourquoi as-tu choisi cette structure de base de données ? » Silence. Puis : « C’est l’IA qui l’a proposée. » Le projet existe, le code tourne, mais la compréhension n’est pas là. Ce scénario, beaucoup d’équipes techniques le vivent chaque semaine en 2026.

Le sujet du développeur junior face à l’IA est devenu l’un des plus discutés de la tech cette année. Au QCon London 2026, Alasdair Allan (CTO chez Negroni Venture Studios, ancien responsable de la documentation chez Raspberry Pi) lui a consacré une conférence très documentée, publiée par InfoQ : « The Ladder is Missing Rungs », l’échelle a perdu ses barreaux (voir la présentation originale). Sa thèse : l’IA générative avale les tâches simples qui servaient de terrain d’apprentissage aux débutants. Les barreaux du bas et du milieu de l’échelle disparaissent, alors que l’entreprise aura plus que jamais besoin de développeurs séniors capables de juger ce que produisent les machines.

Chez Corporate Mavericks, on pense que c’est d’abord un problème de management, pas un problème technique. Voici ce que disent vraiment les études, pourquoi l’apprentissage des profils débutants se dégrade, et ce que vous pouvez faire concrètement, dès ce trimestre, pour former la relève.

L’IA va-t-elle remplacer les développeurs juniors ?

Commençons par calmer le jeu. Il y a un an, Dario Amodei, cofondateur d’Anthropic, annonçait que l’IA écrirait la quasi-totalité du code sous douze mois. Ce n’est pas ce qui s’est passé. Selon les chiffres cités par Alasdair Allan, la part de code généré par IA tourne autour de 25 % chez Google et 30 % chez Microsoft, et une analyse de Redwood Research ramène le fameux « 90 % » d’Anthropic à environ 50 % si l’on ne compte que le code réellement versionné dans Git. C’est énorme, mais ce n’est pas la fin du métier de développeur.

Le vrai changement est plus subtil. Les outils d’IA réussissent presque à 100 % les tâches qui prennent moins de quatre minutes à un humain (petites corrections de bugs, code répétitif, implémentations simples). Ils tombent à environ 50 % de réussite sur une tâche d’une heure, et sous les 10 % au delà de quatre heures, d’après les mesures de l’institut METR. Autrement dit, l’IA excelle exactement sur le travail qu’on confiait jusqu’ici aux débutants pendant leur première année. Et elle échoue là où il faut du jugement, celui qui se construit en faisant ces mêmes tâches pendant des années.

Donc non, l’intelligence artificielle ne remplace pas les développeurs. Mais elle remplace le chemin qui permettait de le devenir. C’est beaucoup plus grave, parce que ça ne se voit pas tout de suite.

Ce que disent les études (pas les posts LinkedIn)

Sources : Anthropic, METR, Faros AI, citées par Alasdair Allan (QCon London 2026)

17 %

de score en moins au test de maîtrise pour les débutants qui ont appris avec l’IA

14 %

de baisse du taux d’accès à l’emploi des 22 à 25 ans dans les métiers exposés à l’IA

+91 %

de temps de revue de code dans les équipes qui ont fortement adopté l’IA

On recrute moins de débutants, ceux qu’on recrute apprennent moins, et le goulot d’étranglement se déplace vers les séniors qui relisent tout.

Le paradoxe de la supervision : apprendre avec l’IA, c’est parfois ne rien apprendre

L’étude la plus frappante vient d’Anthropic, l’éditeur de Claude. Dans un essai contrôlé randomisé, 52 ingénieurs, majoritairement juniors, devaient apprendre une nouvelle bibliothèque Python (Trio, dédiée à la programmation asynchrone). La moitié avait accès à un assistant IA, l’autre non.

• Vitesse : aucune différence statistiquement significative. Le groupe avec IA a gagné environ deux minutes, dans la marge d’erreur.

• Compréhension : au test de maîtrise passé ensuite, le groupe avec IA obtient 50 % contre 67 % pour le groupe sans IA. Un écart significatif.

• Le pire : l’écart le plus large concerne le débogage, c’est à dire précisément la compétence nécessaire pour vérifier ce que produit l’IA.

Anthropic nomme lui même ce phénomène le « paradoxe de la supervision » : utiliser l’IA exige de la superviser, et superviser exige les connaissances techniques qui s’atrophient quand on utilise trop l’IA. Alasdair Allan résume la chose sans détour : ces débutants n’ont pas échangé de l’apprentissage contre de la vitesse, ils ont échangé de l’apprentissage contre rien.

Les 3 comportements qui sabotent l’apprentissage

L’étude identifie trois profils chez les participants qui ont obtenu les plus mauvais scores (sous les 40 %) :

1. La délégation totale : ils n’essaient même pas, l’IA fait tout dès le départ.

2. La dépendance progressive : ils essaient un peu, butent, puis laissent l’IA faire le reste.

3. Le débogage par IA : ils demandent à l’IA de corriger le code de l’IA, sans jamais comprendre ce qui se passe.

Si vous managez une équipe, ces trois comportements sont observables. Ils ne se voient pas dans le nombre de tickets fermés. Ils se voient dans la qualité des réponses quand on pose la question « pourquoi ? ».

L’IA avait les permissions. Il lui manquait les cicatrices.Alasdair Allan, QCon London 2026 (traduit de l’anglais)

Emploi développeur : ce qui change vraiment pour les profils débutants

Le second choc concerne le marché de l’emploi. Une analyse publiée par Anthropic sur l’impact de l’IA sur le travail classe les programmeurs comme le métier le plus exposé : 74,5 % de leurs tâches font déjà l’objet d’un usage automatisé réel. Surtout, chez les 22 à 25 ans, le taux d’accès à un emploi dans les métiers exposés a décroché à partir de 2024, avec une baisse moyenne estimée à 14 %. Aucune baisse n’est observée au delà de 25 ans. Des données de paie ADP vont dans le même sens, avec un recul de 6 à 16 % de l’emploi des 22 à 25 ans dans ces métiers.

Le point clé : personne n’est licencié. Les entreprises ne remplacent pas leurs développeurs séniors, elles arrêtent simplement d’embaucher la génération suivante. Moins d’offres d’emploi « junior » en CDI, plus d’exigences dans chaque annonce (« junior avec trois ans d’expérience sur notre stack »), et des jeunes diplômés qui finissent par postuler en freelance ou en société de conseil faute de mieux. Le secteur digital tout entier est concerné. Sur LinkedIn, les candidats qui cherchent un premier emploi de développeur, de data scientist ou d’ingénieur DevOps racontent tous la même histoire : des centaines de candidatures pour quelques entretiens.

Vu d’un comité de direction, c’est rationnel à court terme : pourquoi recruter et encadrer un débutant quand un développeur expérimenté équipé d’outils d’IA livre la même fonctionnalité plus vite ? Vu à cinq ou dix ans, c’est une bombe à retardement. Les séniors partent à la retraite, changent d’entreprise ou deviennent managers. Si personne n’a gravi l’échelle derrière eux, qui saura concevoir l’architecture, comprendre le code legacy et dire non à un agent IA trop sûr de lui ?

Pourquoi vos développeurs séniors sont en train de couler sous la revue de code

Les données de Faros AI, issues de la télémétrie d’environ 10 000 développeurs répartis dans 1 200 équipes, montrent ce qui se passe quand l’adoption de l’IA grimpe : 21 % de tâches terminées en plus, 98 % de pull requests fusionnées en plus. Bonne nouvelle ? Pas tout à fait. Le temps de revue augmente de 91 %, la taille moyenne des pull requests de 154 %, et le nombre de bugs par développeur de 9 %.

Le goulot d’étranglement ne disparaît pas, il remonte vers la revue de code, là où se trouve le jugement des séniors. Et l’institut METR a mesuré qu’environ la moitié des pull requests générées par IA qui passaient les tests automatisés n’auraient pas été acceptées par les mainteneurs des projets. Manque de documentation, tests insuffisants, non respect des bonnes pratiques : l’IA sait implémenter le cœur d’une fonctionnalité, mais rate régulièrement le soin du travail bien fait, exactement ce que les barreaux du milieu de l’échelle sont censés enseigner.

Ajoutez à cela un effet de bord rarement mesuré : chez Anthropic, les ingénieurs déclarent poser 80 à 90 % de leurs questions à Claude plutôt qu’à leurs collègues. Un ingénieur sénior y confiait trouver triste que les juniors ne viennent plus le voir. L’apprentissage informel, celui qui naît d’une session de débogage à deux devant un écran, s’évapore. Le télétravail généralisé avait déjà fragilisé cette transmission, l’IA l’accélère. Nous avons détaillé les limites des métriques de vélocité dans notre article sur la productivité des développeurs avec l’IA et dans celui sur le ROI de l’IA.

Tu veux des équipes qui apprennent, pas juste des équipes qui livrent ?

Chaque semaine, on décortique ce qui marche vraiment en management, en organisation et en transformation. Zéro jargon, zéro bullshit.

Le vrai risque : une organisation qui perd sa mémoire

Alasdair Allan s’appuie sur les incidents récents chez Amazon, en précisant que les versions divergent. Selon le Financial Times, un agent de codage IA aurait choisi de supprimer puis recréer tout un environnement de production d’AWS Cost Explorer, provoquant treize heures de rétablissement. Amazon parle d’une erreur humaine liée à des droits d’accès mal configurés. Pour une panne du site marchand, Amazon reconnaît en revanche qu’un ingénieur a suivi un conseil erroné qu’un outil d’IA avait déduit d’une page de wiki interne obsolète.

Quelle que soit la version retenue, la leçon est la même : l’IA lit tout ce qu’on lui donne avec le même niveau de confiance. Elle ne sait pas qu’une page date de cinq ans ni qu’une règle métier cachée dans une condition protège 0,1 % de vos clients. Seule une personne qui a vécu avec le système le sait. Ce savoir, c’est précisément ce que les débutants accumulaient en corrigeant des bugs, en lisant du vieux code et en participant aux incidents de production.

Une étude de GitClear portant sur 211 millions de lignes de code confirme la tendance : avec l’adoption de l’IA, le refactoring chute de 60 %, le copier coller augmente de 48 % et le code réécrit peu après sa création grimpe de 44 %. On produit plus, on comprend moins ce qui existe déjà.

Comment former un développeur junior à l’ère de l’IA : 6 leviers concrets

Alasdair Allan reconnaît honnêtement ne pas avoir de solution miracle. Il propose cependant des pistes, que nous complétons avec ce que nous voyons fonctionner chez nos clients :

1. Créer un internat, comme en médecine. Faire tourner les débutants sur le travail fondamental (corriger des bugs, écrire des tests, lire du code legacy) même si l’IA le ferait plus vite. On fait ce travail parce qu’il forme, pas parce qu’il est efficace. Les médecins ne sont pas formés autrement.

2. Exiger la compréhension avant l’assistance. Le débutant formule d’abord son hypothèse, sa piste de solution, puis seulement il demande à l’IA. L’outil devient un sparring partner, pas un pilote automatique.

3. Mesurer la compréhension, pas la vélocité. En revue ou en binôme, poser trois questions : que fait ce code ? Saurais tu le déboguer sans IA ? Que se passe t il s’il échoue ? Le pair programming devient un outil d’évaluation : on regarde comment la personne réfléchit, pas seulement ce qu’elle produit.

4. Traiter le contexte comme une infrastructure. Documenter les décisions d’architecture avec leur justification, tenir à jour le wiki, écrire des fichiers de contexte qui se lisent comme un guide d’accueil. Cette documentation sert à la fois aux agents IA et aux nouveaux arrivants.

5. Budgéter l’apprentissage. Si un sénior passe 20 % de son temps à encadrer, ce temps doit apparaître dans la planification, pas être grappillé le soir. Sans budget, le mentorat disparaît au premier rush.

6. Dire la vérité aux juniors. L’IA est un outil, pas un professeur. L’utiliser pour sauter l’étape de compréhension, c’est emprunter sur son avenir professionnel. Ceux qui auront de la valeur dans dix ans seront ceux qui comprennent les systèmes, pas ceux qui savent seulement écrire un prompt.

Ces leviers touchent la culture autant que les process. Ils rejoignent ce que nous défendions dans notre article sur le vibe coding en entreprise : tout le monde peut produire du code avec l’IA, mais sans personne pour trier et comprendre, la dette s’accumule en silence. Et ils supposent un vrai esprit critique face à l’IA.

Et si vous êtes développeur junior : comment rester employable

Si vous cherchez votre premier poste ou que vous débutez, quelques principes simples font la différence face à un recruteur :

• Codez une partie de vos projets personnels sans IA. Pas par purisme, mais pour pouvoir expliquer chaque ligne en entretien.

• Apprenez à déboguer. C’est la compétence qui creuse le plus l’écart dans l’étude d’Anthropic, et celle que les recruteurs vont rechercher en priorité.

• Montrez votre raisonnement. Un historique Git propre, des choix d’architecture justifiés, des tests : tout ce qui prouve que vous comprenez ce que vous livrez.

• Utilisez les LLM pour apprendre. Demandez à l’IA d’expliquer, de critiquer votre code, de vous poser des questions, plutôt que de lui faire écrire la solution.

• Visez les équipes qui encadrent. En entretien, demandez comment l’équipe forme ses débutants. Une entreprise qui n’a pas de réponse claire risque de vous transformer en opérateur d’IA.

Le développeur junior face à l’IA en trois phrases

1. L’IA fait très bien le travail qui formait les débutants, et très mal le travail qui demande du jugement.

2. Arrêter de recruter et de former des juniors fait gagner du temps aujourd’hui et coûtera votre capacité à superviser l’IA demain.

3. Former la relève est un choix de management : du temps budgété, des pratiques d’apprentissage explicites, et des indicateurs de compréhension plutôt que de vitesse.

Vous voulez repenser l’intégration et la montée en compétences de vos équipes à l’heure de l’IA ? Réservez un appel stratégique avec Corporate Mavericks.

FAQ : développeur junior et IA

Pas à court terme. L’IA écrit une part importante du code (environ 25 à 30 % chez Google ou Microsoft selon leurs propres chiffres), mais elle échoue encore souvent sur les tâches longues qui demandent du jugement, de l’architecture et une connaissance du contexte. Elle transforme le métier de développeur vers plus de conception, de relecture et de supervision, plutôt qu’elle ne le supprime.Oui, les premières données le montrent. L’analyse d’Anthropic sur le marché du travail observe depuis 2024 une baisse d’environ 14 % du taux d’accès à l’emploi des 22 à 25 ans dans les métiers les plus exposés à l’IA, sans effet sur les plus de 25 ans. Les entreprises licencient peu, mais recrutent moins de débutants.En France, les baromètres 2026 situent généralement un premier CDI entre 30 et 45 k€ brut annuel, selon le diplôme, la ville, la stack et le type d’entreprise (start up, grand groupe, société de conseil). Les écoles d’ingénieurs et les profils spécialisés en data ou en IA se situent plutôt dans le haut de la fourchette.Un développeur spécialisé en IA (machine learning, LLM, IA générative) est en général mieux payé qu’un développeur généraliste à expérience égale, car l’expertise reste rare. Les écarts dépendent fortement de l’expérience réelle sur des projets IA en production, bien plus que des certifications.Les études d’exposition montrent que les métiers physiques (artisans, mécaniciens, cuisiniers) sont aujourd’hui les moins touchés. Dans la tech, les rôles qui combinent jugement, connaissance du contexte et responsabilité (architecture, sécurité, management d’équipes techniques, relation client) résistent mieux que les tâches d’exécution pure.Comme un tuteur exigeant, pas comme un pilote automatique : formuler sa propre hypothèse avant de demander, faire expliquer le code généré, s’entraîner à déboguer sans assistance, et garder une partie de ses projets écrits à la main. L’objectif est de pouvoir justifier chaque choix technique devant un recruteur ou un développeur sénior.

Former la relève, c’est un choix de leader

Rejoins la newsletter Corporate Mavericks : chaque semaine, des idées concrètes pour manager autrement, sans langue de bois.

Votre slide dit « +30 % de vélocité depuis l’arrivée de l’IA ». Votre DAF demande ce que rapporte la facture. Ce ne sont pas du tout les mêmes questions.

Mesurer le ROI de l’IA n’est pas un problème de tableau de bord. C’est une question de méthode, d’honnêteté et de management.

Fin 2026, la question du ROI de l’IA est arrivée dans toutes les directions financières. Les licences d’assistants de code, les abonnements aux outils d’IA générative et la facture de tokens des agents ont grimpé plus vite que n’importe quelle autre ligne du budget IT. Le DAF pose donc une question parfaitement légitime : qu’est-ce que cet investissement nous rapporte, et comment le savons-nous ?

La réponse qui circule dans la plupart des entreprises tient sur une slide : la vélocité de l’équipe avant le déploiement de l’IA, la vélocité après, une flèche verte et un pourcentage. Ce chiffre remonte ensuite de comité en comité jusqu’au board. Problème : il ne répond pas à la question posée.

Stefan Wolpers, Professional Scrum Trainer et auteur du Scrum Anti-Patterns Guide, vient de le démontrer méthodiquement dans un article publié le 1er novembre 2026 sur Age of Product, « Measuring AI Impact: What Your Velocity Chart Cannot Tell the CFO ». Il s’appuie notamment sur la série publiée en septembre 2026 par James Shore, figure historique de l’agilité, sur la mesure de l’impact de l’IA. Leur conclusion commune est inconfortable pour beaucoup de managers : le retour sur investissement de l’IA ne se lit pas dans un burndown chart. Voici pourquoi, et comment produire une réponse que votre direction financière peut réellement signer.

Pourquoi la question du ROI de l’IA arrive maintenant sur la table

En 2025, l’adoption de l’IA en entreprise relevait encore largement de l’expérimentation. On distribuait des licences, on lançait des ateliers de prompt, on célébrait les premiers cas d’usage. Personne ne demandait de chiffres précis : l’important était de ne pas rater le train.

En 2026, le décor a changé. Les investissements dans l’IA sont devenus une ligne budgétaire significative, avec des coûts récurrents (licences, infrastructure, tokens, maintenance des intégrations, conformité) et des coûts cachés (formation des équipes, temps de vérification, gouvernance de l’IA). Les agents autonomes, qui consomment des tokens en continu, rendent la facture moins prévisible. Et la promesse d’un avantage concurrentiel ne suffit plus à justifier le budget total.

Début 2026, l’adoption de l’IA n’était déjà plus une option dans la plupart des entreprises. Leur maturité en matière de mesure, en revanche, est restée très faible : on sait combien coûte l’IA, beaucoup moins ce qu’elle rapporte. Les gains directs (temps gagné sur une tâche) sont mis en avant, les coûts de conformité et de relecture passent sous le radar.

Nous avons déjà expliqué pourquoi rationner l’IA pour réduire les coûts est une mauvaise réponse. Mais l’inverse est tout aussi dangereux : dépenser sans savoir ce qui crée de la valeur. Entre les deux, il y a une discipline à apprendre, celle de mesurer honnêtement.

Pourquoi la vélocité est le pire indicateur pour calculer le ROI de vos projets IA

La vélocité additionne des story points, c’est-à-dire des estimations faites par l’équipe avant que le travail commence. Leur valeur, rappelle Wolpers, a toujours été la conversation qu’elles provoquent, pas le nombre. Utiliser ce nombre pour mesurer la productivité était déjà discutable. L’utiliser pour mesurer l’impact de l’intelligence artificielle l’est encore plus, pour trois raisons.

1. Le « avant/après » attribue tout à l’IA

Les équipes changent rarement une seule chose à la fois. Les assistants de code arrivent le même trimestre qu’une réorganisation, un départ, une nouvelle cadence de sprint ou une release majeure. Comparer avant et après crédite l’IA de tous ces changements. Et le « avant » n’est pas forcément un point de référence calme : si le déploiement a suivi une période de rush, ou si les gens utilisaient déjà l’IA en douce avant les licences officielles, vous mesurez aussi ça. La question à poser devant chaque chiffre avant/après est simple : qu’est-ce qui a changé d’autre ce mois-là ?

2. L’IA change les estimations elles-mêmes

Si l’équipe pense que l’IA la rend plus rapide, ses estimations baissent, et un vrai gain peut disparaître de la courbe. À l’inverse, si la direction attend un « boost de vélocité IA », une équipe sous pression trouvera vite que le même travail mérite plus de points. C’est la loi de Goodhart : dès qu’une mesure devient un objectif, elle cesse d’être une bonne mesure. Wolpers en fait un exercice dans ses formations Scrum, « Cooking the Agile Books » : gonfler sa vélocité sans travailler plus. Tout le monde sait le faire. Avant et après le déploiement de l’IA, la vélocité n’est donc plus exprimée dans la même unité.

3. La vélocité ignore le travail de réparation

Les bugs, les tickets rouverts, les correctifs manuels, le support que personne n’avait planifié : tout ce travail n’apparaît jamais dans la vélocité. Or le rapport DORA 2025, qui a interrogé près de 5 000 professionnels de la tech, observait à la fois une relation positive entre adoption de l’IA et débit de livraison, et une instabilité des livraisons qui continue d’augmenter. Plus de travail livré et plus de travail de réparation peuvent apparaître dans les mêmes sprints. Une slide qui ne montre que le premier chiffre laisse le second à celui qui est d’astreinte le week-end.

Conseil pratique de Wolpers : comptez les éléments terminés à côté des points. Si les points par élément augmentent alors que le nombre d’éléments terminés par sprint reste stable, la vélocité monte mais le travail livré, lui, ne bouge pas.

Des gains plus rapides sur le code ne sont pas des gains pour l’organisation

James Shore donne un exemple que tout dirigeant devrait afficher dans son bureau : si l’IA double la vitesse de codage, mais que les développeurs passent la moitié de leur semaine sur autre chose (réunions, coordination, attente de décisions), leur gain global n’est pas de 2x mais de 1,33x. Un assistant de code accélère le code. Il ne fait rien pour la sprint review, la conversation avec les parties prenantes, ou la décision qui attend trois niveaux de hiérarchie plus haut.

C’est exactement ce que nous décrivions dans notre article sur la productivité des développeurs avec l’IA : l’automatisation d’une étape déplace les goulots d’étranglement ailleurs dans les processus. Si le vrai frein de votre organisation est la prise de décision, une IA qui produit du code deux fois plus vite fabrique surtout une file d’attente deux fois plus longue.

« La productivité du développement logiciel, c’est la valeur produite divisée par l’argent dépensé. Aller plus vite ne veut pas dire aller dans la bonne direction. »James Shore, cité par Stefan Wolpers (Age of Product, novembre 2026)

Voilà la formule de base du ROI de l’IA que votre DAF attend : de la valeur, pas de la vitesse. Un projet IA mesurable est un projet dont on peut relier l’usage à un résultat opérationnel ou business, pas à un volume de tickets.

Calculer le ROI de vos projets IA : partir du résultat, pas de l’outil

Les projets IA dont le ROI est le plus simple à démontrer sont ceux qui visent un résultat opérationnel déjà mesuré avant l’arrivée de l’IA : la détection de la fraude (montant de fraude évitée), la maintenance prédictive (pannes et arrêts évités), le traitement de dossiers (délai de traitement de bout en bout). Le résultat existe indépendamment de l’outil, on peut donc comparer. Avant de lancer un projet, commencez par identifier les goulots d’étranglement réels : c’est là que l’IA a une chance de produire un ROI significatif.

À l’inverse, les déploiements d’IA générative « pour tout le monde » sont les plus difficiles à évaluer : le gain est diffus, déclaratif, et rarement relié à un flux de travail précis. Pour calculer le ROI de ce type d’initiative IA, il faut redescendre au niveau du workflow : quelle tâche, faite par qui, combien de fois par semaine, avec quel temps de vérification.

Méfiez-vous aussi des benchmarks publiés par les éditeurs et cabinets : un ROI médian annoncé sur un échantillon de clients enthousiastes ne dit rien de votre contexte, de la qualité de vos données ni de la maturité de vos équipes. Dans les PME et ETI, où le budget total IA est plus serré, cette rigueur compte encore plus. Et n’oubliez pas la montée en compétences : la formation des équipes fait partie de l’investissement, au même titre que les licences.

Le chiffre qui devrait calmer tout le monde

Ce que les équipes ressentent et ce qu’elles mesurent n’a rien à voir.

En juillet 2025, l’organisme de recherche METR a publié une étude randomisée sur 16 développeurs open source expérimentés et 246 tâches, avec ou sans IA tirées au sort. Résultat : avec l’IA, ils ont mis 19 % plus de temps. Avant l’étude, ils s’attendaient à gagner 24 %. Après, ils pensaient encore avoir gagné 20 %.

METR reconnaît que ces résultats ont vieilli et que les outils de 2026 accélèrent probablement davantage. Mais quand l’organisme a interrogé 349 professionnels techniques début 2026, le gain de vitesse médian déclaré était de 3x, avec un avertissement des auteurs eux-mêmes : ces réponses ne sont pas forcément ancrées dans la réalité.

Un sondage de satisfaction mesure un ressenti. Il ne mesure pas un retour sur investissement.

Comment mesurer l’impact de l’IA : les trois niveaux de preuve

Tous les chiffres ne se valent pas. Wolpers propose une grille simple, applicable à chaque affirmation sur l’IA qui arrive sur votre bureau :

• L’essai comparatif : le même type de tâche, réalisé avec et sans IA pendant les mêmes semaines, avec une estimation notée avant, et la condition tirée au sort après. C’est la preuve la plus solide qu’une équipe puisse produire seule. James Shore recommande justement d’alterner des tâches « avec IA » et « sans IA » sur la même période pour neutraliser les autres changements.

• La comparaison avant/après : elle montre, au mieux, une corrélation.

• Le sondage sur la vitesse ressentie : il dit comment les gens se sentent, ce qui est utile à savoir, mais il mesure une perception, pas une vitesse.

Attention à un biais que METR a lui-même rencontré dans son étude de suivi : entre 30 % et 50 % des développeurs ont évité certaines tâches qu’ils ne voulaient pas faire sans IA. Une fois qu’on s’appuie sur l’IA, travailler sans elle ressemble à une punition. Un essai a donc besoin du consentement des participants et d’une date de fin connue de tous.

Marre des slides IA à flèche verte ?

Chaque semaine, on décortique ce que l’IA change vraiment pour les managers, preuves à l’appui.

Le test du point mort : savoir si automatiser une tâche avec l’IA est rentable

Une bonne partie du travail confié à l’IA n’est pas du code : comptes rendus, rapports aux parties prenantes, notes de version, premières versions de user stories. Pour ces délégations, il existe un test beaucoup plus simple, cité par McKinsey dans son article d’octobre 2026 sur la courbe de valeur de l’IA et attribué à David Tepper, CEO d’Ascerta. Confier une tâche à l’IA a un sens économique quand sa probabilité de succès dépasse le rapport entre le temps de vérification et le temps qu’il faudrait pour faire la tâche soi-même.

Taux d’acceptation > temps de vérification ÷ temps de réalisation

La logique est implacable : avec l’IA, on paie toujours le temps de vérification, et quand le résultat échoue au contrôle, on refait la tâche à la main. La part des résultats acceptés doit donc dépasser ce ratio.

L’exemple (fictif) de Wolpers : un rapport mensuel prend 180 minutes à rédiger à la main et 60 minutes à vérifier ligne à ligne. La version IA n’est rentable que si plus d’un brouillon sur trois passe le contrôle. Si la vérification prend 150 minutes, parce que chaque affirmation exige de revenir aux données sources, il faut un taux d’acceptation supérieur à 83 %. Une équipe qui a dû réécrire deux de ses six derniers rapports a sa réponse.

Quatre ajustements évitent de se raconter des histoires :

1. Comptez le temps de vérification de tout le monde. Un Product Owner qui génère cinq descriptions de backlog en 15 minutes, puis trois développeurs qui passent chacun 20 minutes à démêler des phrases plausibles mais fausses : la vérification coûte 60 minutes, payées par des gens qui n’ont rien délégué. Tobi Lütke, CEO de Shopify, appelle ça des « slop grenades ». C’est un transfert de coût, pas un gain, et c’est la mécanique exacte du workslop.

2. Ajoutez le temps passé à écrire et ajuster les prompts, à chaque exécution.

3. Mesurez le temps de vérification au lieu de l’estimer de mémoire. Un souvenir est une estimation comme une autre.

4. Ne tranchez pas après trois essais. Les premières exécutions sont souvent plus lentes, le temps d’apprendre. Un verdict pris pendant ce creux peut s’inverser un mois plus tard.

La facture de tokens est une ligne à part. Pour un agent de code, elle peut être le gros chiffre. Pour un rapport, le temps humain pèse probablement plus lourd. Regardez votre propre facture avant d’affirmer quoi que ce soit.

Le piège du ROI parfait : quand plus personne ne vérifie

Le test du point mort a un angle mort. Imaginez un résumé hebdomadaire généré par IA qui passe le contrôle à chaque fois depuis deux mois, pendant que le temps de relecture est tombé de quinze minutes à une minute. Sur le papier, c’est votre meilleur cas d’usage : 100 % d’acceptation, vérification quasi nulle. En réalité, plus personne ne vérifie. Une tâche d’assistance est devenue une automatisation sans contrôle, sans que personne ne l’ait décidé.

Pour l’éviter, Wolpers propose un audit régulier des délégations à l’IA, une réunion de 45 à 60 minutes toutes les deux semaines ou chaque mois, qui fait pour le travail délégué ce que la rétrospective fait pour la façon de travailler de l’équipe. Quatre contrôles par workflow :

• Dérive du résultat : le travail respecte-t-il toujours la définition de « terminé » ?

• Adéquation du modèle : le niveau de modèle est-il toujours le bon, dans un sens comme dans l’autre ?

• Réversibilité : pourriez-vous arrêter cette automatisation aujourd’hui, et qui le ferait ?

• Glissement : combien de temps un humain passe-t-il réellement à relire ? Une approbation en quatre secondes est un échec.

Chaque workflow reçoit ensuite une décision : garder, modifier ou retirer. « On surveille » n’est pas une décision, c’est une décision repoussée qui se déguise. Et retirer une délégation qui ne paie plus est un succès : l’équipe a appris quelque chose. C’est aussi le meilleur moyen de garder la main sur la prolifération des agents IA en entreprise.

Mesurer l’approche, jamais les personnes

Tout export Jira contient le nom de chaque membre de l’équipe, et une IA à qui l’on demande pourquoi la vélocité a augmenté désignera volontiers un responsable. Dès qu’un bilan d’impact nomme, félicite ou classe des individus, la mesure d’une approche devient une évaluation de performance. Et les gens optimisent l’indicateur au lieu du travail.

James Shore est sans ambiguïté : ses indicateurs ne doivent jamais servir à évaluer la performance des équipes ou des individus. Sa règle tient sur un post-it :

« Mesurez l’approche, apprenez-en, puis arrêtez de mesurer. »James Shore, « Assessing AI Impact: Notes for Your CFO », 2026

La dernière partie est celle que tout le monde oublie. Un essai sur la vitesse s’arrête quand il a répondu à sa question. Installer un programme permanent de mesure de la productivité IA, c’est fabriquer de la surveillance et de la bureaucratie, deux choses dont votre culture n’a pas besoin.

Ce que votre DAF devrait recevoir à la place de la courbe de vélocité

Si la courbe de vélocité ne peut pas répondre, que donner à la direction financière ? Wolpers propose une page unique, que le CTO ou le manager de l’équipe peut signer :

Ce que l’équipe peut affirmer

Chaque affirmation avec sa source et son niveau de certitude. Par exemple : le nombre d’éléments terminés par sprint à côté des bugs et tickets rouverts, ou la décision prise sur un workflow délégué et l’audit qui la justifie.

Ce que l’équipe ne peut pas affirmer, et pourquoi

Par exemple : un pourcentage de productivité causé par l’IA, parce qu’une comparaison avant/après montre au mieux une corrélation. Préciser quelle preuve il faudrait pour pouvoir l’affirmer.

La décision par workflow délégué

Garder, modifier ou retirer, chaque ligne renvoyant à son entrée dans le journal de reclassification.

Trois indicateurs maximum, avec une date de fin

Pas un tableau de bord de quarante métriques. Trois mesures, chacune limitée dans le temps.

Cette page ne nomme personne et ne classe personne. Elle demande aussi un peu de courage, parce que « nous ne pouvons pas affirmer cela » n’est pas ce que promettait la slide de la plénière. Mais une page qui dit « on ne peut rien savoir » échoue autant qu’une page qui répète le pourcentage magique. La création de valeur se prouve, elle ne se proclame pas.

Par où commencer lundi matin : un essai sur un seul workflow

Pas besoin d’un grand projet IA de mesure. Pour votre propre travail, un carnet et quelques semaines suffisent :

1. Choisissez une tâche que vous faites déjà avec l’IA au moins une fois par semaine.

2. Écrivez votre règle de décision avant de commencer : je garde si, je change si, j’arrête si. Une fois les chiffres arrivés, chacun ressemble à une bonne raison de faire ce que vous vouliez déjà.

3. Prévenez la personne qui reçoit le résultat, pour qu’un livrable fait à la main soit compris comme un test.

4. Avant chaque exécution, notez votre estimation, puis tirez au sort avec ou sans IA (cinq papiers de chaque dans un mug, plus équilibré qu’une pièce sur dix essais).

5. Après chaque exécution, notez le temps total, vérification et reprise comprises, et si le résultat a passé votre contrôle.

6. Après huit à dix essais, comparez le ratio médian temps réel / estimation avec et sans IA, puis calculez votre point mort.

7. Appliquez votre règle, notez la décision, et arrêtez de mesurer.

Huit à dix essais ne convaincront pas un statisticien. Mais ils donnent une direction, et une direction suffit pour décider du sort d’un workflow. C’est infiniment plus honnête qu’une flèche verte, et c’est le genre de preuve qu’un DAF respecte.

Le ROI de l’IA n’est pas un chiffre qu’on trouve, c’est une discipline qu’on installe. Les organisations qui sauront dire « ça marche ici, pas là, et voici pourquoi » feront de l’IA un vrai levier. Les autres continueront de financer des slides.

Questions fréquentes sur le ROI de l’IA

Partez de la formule de base du retour sur investissement : valeur produite divisée par l’argent dépensé, et non vitesse de production. Pour un workflow délégué, utilisez le test du point mort : le taux d’acceptation des résultats doit dépasser le rapport entre le temps de vérification et le temps de réalisation à la main. Ajoutez les coûts complets (licences, tokens, infrastructure, maintenance, formation, temps de prompt et de relecture de toute l’équipe).La vélocité additionne des estimations faites avant le travail. Le déploiement de l’IA modifie ces estimations (à la baisse si l’équipe pense aller plus vite, à la hausse si la direction attend un gain), coïncide souvent avec d’autres changements, et ignore le travail de réparation comme les bugs et les tickets rouverts. Avant et après, la vélocité n’est plus mesurée dans la même unité.Peu d’indicateurs, limités dans le temps : nombre d’éléments réellement terminés à côté des bugs et tickets rouverts, taux d’acceptation et temps de vérification par workflow délégué, et indicateurs de résultat business ou client. Évitez les sondages de vitesse ressentie comme preuve : ils mesurent une perception.Le délai de retour dépend du cas d’usage, mais il faut éviter de juger trop tôt. Les premières exécutions sont souvent plus lentes, le temps d’apprendre à rédiger les prompts et à vérifier efficacement. Un essai de huit à dix exécutions sur quelques semaines donne déjà une direction exploitable pour un workflow donné.Non. Mesurez l’approche, pas les personnes. Dès qu’un bilan d’impact nomme ou classe des individus, il devient une évaluation de performance et les gens optimisent l’indicateur au lieu du travail. Seule observation utile : si le gain est concentré sur une seule personne, l’équipe ne peut pas revendiquer un effet collectif.Souvent parce que l’IA accélère une étape qui n’était pas le goulot d’étranglement, parce que le temps de vérification est reporté sur d’autres équipes, ou parce que la qualité des données et des résultats n’est jamais contrôlée. Un audit régulier des délégations permet de garder, modifier ou retirer chaque cas d’usage avant qu’il ne coûte plus qu’il ne rapporte.

L’IA sans le bullshit, chaque semaine

Une newsletter pour les managers qui veulent des preuves, pas des flèches vertes. Zéro hype, que du concret.

Grâce à l’IA, n’importe qui peut désormais coder une fonctionnalité en un après-midi. Le problème, c’est que plus personne ne décide si elle mérite d’exister.

Le vibe coding en entreprise ne pose pas un problème de technologie. Il pose un problème de tri, de responsabilité et de management.

Le vibe coding en entreprise est passé en quelques mois du gadget de hackathon à la stratégie officielle. On décrit ce qu’on veut en langage naturel, un assistant IA génère le code, on clique, ça tourne. Designers, product managers, marketeurs, et même certains managers se retrouvent capables de livrer une application fonctionnelle sans écrire une ligne de code à la main. Les directions adorent : enfin une IA qui produit quelque chose de visible.

Sauf que Jeff Gothelf, coauteur de Lean UX, vient de poser la question qui fâche dans un article publié fin octobre 2026, « How to manage the inevitable mess of running a company where everyone is a builder ». Son constat : l’IA a supprimé le filtre qualité qui empêchait les mauvaises idées d’arriver en production. Et quand tout le monde devient « builder », plus personne n’a pour mission de dire non.

Chez Corporate Mavericks, on se méfie autant de la bureaucratie que du chaos. Le vibe coding est une formidable nouvelle façon de coder et de valider une idée. Mais si votre organisation le traite comme une machine à fonctionnalités, vous allez fabriquer à grande vitesse un produit que vos utilisateurs ne comprendront plus. Voici pourquoi, et comment l’éviter.

Qu’est-ce que le vibe coding (et pourquoi tout le monde en parle en 2026) ?

Le terme a été lancé en février 2025 par Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla. Il décrivait une manière de programmer où l’on « se laisse porter par les vibes » : on formule une intention dans un prompt, l’intelligence artificielle produit le code, on teste le résultat et on itère, sans forcément lire ni comprendre chaque ligne de code générée. Le développeur ne tape plus, il dirige.

En 2026, les outils de vibe coding ont rendu cette pratique accessible bien au-delà des équipes techniques. Cursor, Claude Code, GitHub Copilot et une foule d’éditeurs d’applications web permettent de créer une application complète (interface, base de données, authentification) à partir de quelques phrases. Les agents IA vont plus loin encore : ils travaillent de manière autonome sur plusieurs fichiers, modifient le code existant, lancent les tests et poussent le résultat sur GitHub.

Pour un développeur expérimenté, c’est un gain de temps réel sur les tâches répétitives. Pour les débutants et les profils non techniques, c’est une porte ouverte : ils peuvent enfin coder un prototype fonctionnel sans attendre trois sprints qu’une équipe soit disponible. Sur le papier, tout le monde gagne. Dans les faits, le vibe coding change surtout une chose : il rend la production de code presque gratuite. Et quand quelque chose devient gratuit, on en produit beaucoup trop.

Vibe coding en 2026 : du prototype du vendredi au poste de « builder »

Gothelf raconte une scène très ordinaire. Lors d’une fête de famille, il discute avec deux cousins qui travaillent dans la tech : l’une est designer dans une entreprise d’environ 100 personnes, l’autre group product manager dans une structure de 4 000 salariés. Leurs réponses sont presque identiques. Dans les deux entreprises, comme LinkedIn l’avait annoncé l’année précédente, on fusionne les rôles de designer UX et de product manager en un seul poste. Ici on l’appelle « creator », là-bas « builder ». Dans les deux cas, cette personne doit emmener une idée de la conception jusqu’à la production. Et dans les deux cas, personne n’a vraiment réfléchi à la manière dont ça allait fonctionner.

À 100 personnes, avec une dizaine de profils produit et design, le risque reste gérable. À 4 000 personnes, avec une équipe produit et UX de 350 personnes, c’est une autre histoire : 350 nouveaux builders capables de coder et de pousser du code généré vers vos clients. Et dans les grands groupes qui comptent 1 000 ou 5 000 personnes côté produit ? Gothelf pose la question sans détour : comment garder un minimum de discipline sur ce qui est réellement livré, et pourquoi ?

« Beaucoup d’entreprises se débarrassent du rôle produit en disant que tout le monde sera simplement builder. Je pense que c’est une très mauvaise idée. Oui, vous savez utiliser Excel, mais vous ne pouvez pas pour autant travailler dans l’équipe finance. »Andrew Ambrosino (OpenAI), sur le podcast de Lenny Rachitsky, cité par Jeff Gothelf

Tout est dit. Savoir générer du code ne veut pas dire savoir quoi construire. Le vibe coding démocratise la fabrication, pas le jugement.

Le processus de livraison n’a jamais été que de la bureaucratie

On adore taper sur les processus. Nous les premiers : la bureaucratie qui transforme chaque décision en parcours du combattant tue l’initiative et ralentit tout le monde. Mais il faut être honnête sur ce que faisait réellement la chaîne de développement logiciel classique. Revue de code, QA, contrôles de sécurité, tests de performance, déploiements progressifs : tout cela coûtait cher et prenait du temps. Et c’est précisément parce que c’était lent et coûteux que beaucoup de mauvaises idées n’arrivaient jamais jusqu’au client.

Le vibe coding a fait sauter ce filtre. Le chemin vers la production est devenu plus simple, plus rapide, plus accessible. Résultat, selon Gothelf : une pression écrasante pour sortir toujours plus de fonctionnalités et « voir ce qui marche », avec du code plus risqué qui n’a pas toujours atteint le niveau de qualité d’avant. Concrètement, cela veut dire :

• Des failles de sécurité introduites par du code que personne n’a vraiment relu, notamment sur l’authentification et les accès à la base de données ;

• Des données personnelles manipulées par des applications créées hors de tout cadre de conformité ;

• De la dette technique qui s’accumule plus vite que les équipes ne peuvent la rembourser ;

• Des bugs que plus personne ne sait corriger, parce que celui qui a « vibe codé » la fonctionnalité ne comprend pas le code généré.

Et le gain de productivité lui-même commence à se tasser. InfoQ rapportait en octobre 2026, à partir de l’enquête Developer Experience d’Atlassian, que la part des développeurs déclarant gagner plus de dix heures par semaine grâce à l’IA était tombée de 68 % à 26 % en un an : corriger ce que produit l’IA ajoute de la friction, et seuls 42 % des dirigeants disent disposer des bons indicateurs. Nous avions déjà décortiqué ce paradoxe dans notre article sur la productivité des développeurs avec l’IA : accélérer le code ne sert à rien si l’organisation autour ne suit pas.

Le vrai angle mort

La plupart des entreprises ne suppriment jamais rien.

En 2019, bien avant l’IA générative, le rapport Feature Adoption de Pendo estimait que 80 % des fonctionnalités d’un logiciel moyen étaient rarement ou jamais utilisées. Le vibe coding multiplie la capacité à livrer, pas la capacité à retirer.

Quand Gothelf demande à ses cousins à quelle fréquence leur entreprise supprime une fonctionnalité, la réponse est la même : jamais. L’un d’eux cite une fonctionnalité livrée sans soutien de l’équipe produit, qui rapporte un million de dollars de revenu récurrent par an. Elle coûte plus cher à maintenir qu’elle ne rapporte. Mais allez proposer de tuer une fonctionnalité « à un million ».

Chaque fonctionnalité livrée doit ensuite être maintenue, documentée, sécurisée, migrée, expliquée et vendue. Pour toujours. Que quelqu’un l’utilise ou non.

Tu veux plus d’analyses comme celle-ci, sans la hype IA ?

Chaque semaine, on décortique ce que l’IA change vraiment pour les managers et les organisations.

Discovery automatisée : quand l’IA trouve toutes vos idées « viables »

Le détail le plus inquiétant de l’article de Gothelf concerne la product discovery. Dans l’une des entreprises de ses cousins, des équipes ont construit des skills Claude censées « faire la discovery » à leur place. L’agent fouille les offres des concurrents, les données analytiques internes, les bases de verbatims clients et un stock de profils utilisateurs synthétiques, puis rend son verdict sur la viabilité de l’idée. Avec, en prime, des maquettes cliquables générées en quelques minutes.

Le verdict ? Gothelf le résume d’une parenthèse cinglante : l’idée est toujours viable. Évidemment. Un outil d’IA à qui l’on demande de justifier une idée trouvera toujours des arguments pour la justifier. Le vibe coding ne s’arrête donc plus au code : il s’étend à la décision elle-même. On ne valide plus une idée auprès de vrais utilisateurs, on la fait valider par une machine qui ne dit jamais non.

C’est exactement le piège que nous décrivions à propos du workslop, ce contenu généré par IA qui a l’air sérieux mais déplace le vrai travail sur quelqu’un d’autre. Ici, le « workslop » ne finit pas dans une boîte mail : il finit dans votre produit, sous les yeux de vos clients. Un MVP n’a de valeur que s’il sert à apprendre quelque chose. Un prototype qu’on livre sans hypothèse ni critère de succès n’est pas un MVP, c’est une fonctionnalité de plus à maintenir.

5 garde-fous pour qu’un projet vibe coding ne tourne pas au chaos

Gothelf ne plaide pas pour revenir en arrière. Les rôles évoluent, et c’est très bien. Il propose cinq principes pour que le rôle de builder réussisse. Les voici, avec notre lecture Corporate Mavericks.

1. Séparer le droit de construire du droit de livrer

Tout le monde peut coder un prototype. Parfait, laissez faire. Mais l’exposition aux clients suit un chemin précis : d’abord sur sa machine devant quelques utilisateurs potentiels, puis auprès d’utilisateurs internes ou d’une petite cohorte, et seulement ensuite en disponibilité générale. À chaque étape, on présente des preuves pour justifier d’aller plus loin. Le risque augmente uniquement quand l’évidence augmente.

2. Rien ne part en production sans hypothèse, critère de succès et date de revue

Avant de livrer, le builder écrit pourquoi il a construit cette fonctionnalité, qui va l’utiliser et quel impact il en attend pour l’utilisateur et pour le business. Le format importe peu. Ce qui compte : une date fixée pour revenir dessus et décider de tuer, pivoter ou persévérer. C’est la logique de « Who does what by how much? », le livre de Gothelf sur les OKR : mesurer un changement de comportement, pas une livraison.

3. Organiser une revue de retrait chaque trimestre

Une fois par trimestre, l’équipe passe en revue ce qui a été livré, comment ça a performé, ce que ça coûte à construire et à maintenir. Tout ce qui n’a pas atteint ses critères de succès, ou qui n’a plus de propriétaire, doit être corrigé, réattribué ou retiré de la production. Supprimer devient un acte normal de gestion, pas un drame politique.

4. Construire avec l’ingénierie des chemins de déploiement rapides et guidés

Si la mise en production reste un chemin séparé, il doit être rapide. L’objectif : qu’un builder conforme passe les étapes en quelques heures, ou reçoive immédiatement un retour exploitable. Tests automatiques, contrôles de sécurité, vérification de conformité intégrés au pipeline. Sinon, les gens contourneront le process, et vous aurez recréé du shadow IT avec un éditeur de code en plus.

5. Arrêter de mesurer le succès au nombre de fonctionnalités livrées

Si vos builders sont évalués sur le volume livré, vous aurez du volume, et donc encore plus de déchets générés par IA en production. Tenez-les responsables de ce qui compte vraiment : le changement de comportement des clients, l’impact business, la stabilité. Ce qui aurait toujours dû être la règle.

Ce que le vibe coding change vraiment pour le management

Le réflexe de beaucoup de directions sera de répondre au chaos par un comité. Un comité d’architecture, un comité IA, un comité de validation des fonctionnalités. Mauvaise idée. Vous aurez la lenteur de l’ancien monde sans en avoir la qualité, et les équipes vibe coderont quand même, en douce. Nous l’avons montré à propos de la bureaucratie en entreprise : chaque règle ajoutée ralentit, sans forcément protéger.

Le vrai sujet est ailleurs. Grâce au vibe coding, le coût de fabrication s’effondre, donc la rareté se déplace. Ce qui devient rare, c’est le jugement : savoir quoi construire, pour qui, et quand s’arrêter. Trois conséquences pour les managers :

• La responsabilité doit être explicite. Chaque fonctionnalité a un propriétaire humain nommé, qui répond de son succès comme de son retrait. Même principe que pour les agents IA en entreprise : pas de propriétaire, pas de production.

• Les compétences techniques ne disparaissent pas, elles changent de place. Vos développeurs deviennent les garants de la qualité, de la sécurité et de l’architecture. Les débutants et les profils non techniques ont besoin d’une formation structurée pour comprendre ce qu’ils livrent : lire un diff, repérer une donnée sensible, savoir quand demander une revue.

• La discovery redevient un travail humain. Utiliser l’IA pour préparer des entretiens ou synthétiser des retours, oui. Lui déléguer la décision de ce qui mérite d’exister, non. Le contact avec de vrais utilisateurs reste le seul antidote à la machine qui dit oui à tout.

Autrement dit : le vibe coding n’est pas un problème d’outillage. C’est un test grandeur nature de la maturité produit de votre organisation. Les entreprises qui savaient déjà dire non vont décoller. Celles qui livraient pour livrer vont simplement livrer plus vite dans le mur.

Par où commencer lundi matin ?

Pas besoin d’un grand programme de transformation. Quatre gestes simples suffisent pour reprendre la main sur votre projet vibe coding :

1. Faites l’inventaire. Combien de fonctionnalités ou d’applications ont été créées par IA ces six derniers mois ? Qui en est propriétaire ? Qui les utilise ?

2. Ajoutez trois lignes obligatoires à toute demande de mise en production : hypothèse, critère de succès, date de revue.

3. Bloquez une première revue de retrait dans le calendrier du trimestre, avec un objectif explicite : supprimer au moins une fonctionnalité.

4. Changez un indicateur. Remplacez « nombre de fonctionnalités livrées » par un indicateur de résultat client dans vos revues d’équipe.

Le vibe coding est une chance réelle : il permet de tester plus d’idées, plus vite, avec moins de gaspillage en amont. À condition de ne pas confondre la capacité de livrer avec l’obligation de livrer.

Questions fréquentes sur le vibe coding en entreprise

L’expression a été popularisée en février 2025 par Andrej Karpathy, cofondateur d’OpenAI. Elle décrit une façon de coder où l’on décrit ce que l’on veut en langage naturel et où l’on se laisse porter par les propositions de l’IA, en testant le résultat plutôt qu’en écrivant et relisant chaque ligne de code.« Vibe » signifie ambiance, ressenti. Dans vibe coding, l’idée est de programmer à l’intuition : on suit le ressenti du résultat obtenu plutôt qu’une conception technique détaillée. C’est efficace pour un prototype, risqué pour une application en production.Séparez le droit de construire du droit de livrer : tout le monde peut prototyper, mais la mise en production exige une hypothèse, un critère de succès, un propriétaire nommé et une date de revue. Ajoutez une revue trimestrielle pour retirer ce qui ne sert pas, et mesurez l’impact client plutôt que le nombre de fonctionnalités.Il n’y a pas de meilleur outil universel. Cursor, Claude Code ou GitHub Copilot conviennent aux développeurs qui travaillent sur du code existant, tandis que des générateurs d’applications web visent les profils non techniques. Pour une entreprise, le critère décisif n’est pas l’outil mais le cadre : revue de code, sécurité, conformité et propriétaire de chaque fonctionnalité.Pas par défaut. Le code généré peut contenir des failles de sécurité, mal gérer l’authentification ou exposer des données personnelles. Il faut l’encadrer avec des tests automatisés, des contrôles de sécurité dans le pipeline de déploiement et une revue humaine avant toute exposition aux clients.Non. Il déplace leur rôle. Les développeurs deviennent les garants de l’architecture, de la qualité et de la sécurité, et ils restent indispensables pour comprendre, corriger et maintenir le code généré. Ce qui devient rare, ce n’est pas la capacité à produire du code, c’est le jugement sur ce qui mérite d’être construit.

L’IA sans le bullshit, chaque semaine

Une newsletter pour les managers qui veulent profiter de l’IA sans transformer leur produit en cimetière de fonctionnalités. Zéro hype, que du concret.

Chaque équipe a créé son agent IA. Personne ne sait combien il y en a, ce qu’ils font, ni qui répond de leurs actes.

Bienvenue dans l’ère de l’« agent sprawl » : la prolifération des agents IA en entreprise, et ce qu’elle révèle de votre management.

Les agents IA en entreprise se multiplient plus vite que n’importe quelle technologie avant eux. Un agent pour trier les tickets du support, un agent pour rédiger les comptes rendus, un agent pour relancer les clients, un agent pour préparer le backlog, un agent bricolé un vendredi soir par un développeur motivé. Chacun, pris isolément, fait gagner du temps. Ensemble, ils forment un écosystème que plus personne ne pilote.

Le phénomène a désormais un nom : l’agent sprawl, littéralement l’étalement ou la prolifération des agents. Atlassian vient de lui consacrer une analyse détaillée, « Tackling agent sprawl across the enterprise », et le cabinet Gartner a publié en 2026 une série de recommandations pour le maîtriser. Les chiffres donnent le vertige : d’ici 2028, une grande entreprise du Fortune 500 utiliserait en moyenne plus de 150 000 agents. Et seulement 13 % des organisations estiment disposer aujourd’hui de la bonne gouvernance pour les encadrer.

Chez Corporate Mavericks, on n’a aucune envie d’ajouter une couche de comités d’approbation au-dessus de l’IA. Mais on a encore moins envie de voir des milliers d’agents agir au nom de vos équipes sans que personne ne sache qui en est responsable. Parce qu’au fond, l’agent sprawl n’est pas un problème technique. C’est un problème de responsabilité, donc un problème de management.

Qu’est-ce qu’un agent IA (et pourquoi ce n’est pas un chatbot de plus) ?

Un assistant IA classique répond à vos questions : vous posez une demande, il produit un texte, vous décidez quoi en faire. Un agent IA va plus loin. C’est un système logiciel qui reçoit un objectif, découpe le travail en étapes, utilise des outils (votre messagerie, votre CRM, Jira, Confluence, un tableur, une API) et prend des décisions de manière autonome pour atteindre cet objectif. Il ne se contente pas de suggérer : il agit.

Concrètement, un agent peut lire les demandes clients entrantes, les classer, rédiger une réponse, créer un ticket, mettre à jour un statut, prévenir la bonne personne. Un agent autonome peut enchaîner des dizaines d’actions sans qu’un humain valide chacune d’elles. C’est précisément ce qui fait sa valeur, et c’est précisément ce qui le rend risqué : confier à une IA le droit de prendre des décisions dans les processus de l’entreprise, c’est déléguer une part de responsabilité.

Il existe plusieurs types d’agents IA :

• Les agents personnels, créés par un collaborateur pour automatiser ses propres tâches (trier ses mails, préparer ses réunions).

• Les agents d’équipe, configurés pour un processus partagé (qualification des tickets, revue de documentation, onboarding).

• Les agents métier transverses, branchés sur les applications métier et les données d’entreprise pour traiter des processus complets (facturation, recrutement, support client).

• Les agents de développement, qui écrivent, testent ou relisent du code, de plus en plus intégrés aux outils des développeurs.

Le problème n’est pas l’existence de ces agents intelligents. Le problème, c’est que les plateformes rendent la création d’un agent aussi simple que la création d’un document partagé. Et vous savez ce qui arrive aux documents partagés quand personne ne fait le ménage.

Agent sprawl : quand les agents IA en entreprise prolifèrent sans pilote

Le scénario est toujours le même. La direction pousse l’adoption de l’IA générative. Les équipes s’emparent des outils, chacune à sa manière. Le marketing crée ses agents, le support crée les siens, la finance aussi, et les développeurs en déploient d’autres dans leurs pipelines. Les déploiements se font dans l’urgence, sans contexte partagé, sans propriétaire clair, sans supervision coordonnée.

Atlassian résume bien le paradoxe : les gains de productivité individuels ne se transforment pas automatiquement en résultats pour l’organisation. Des efficacités isolées peuvent très vite tourner à la prolifération. Selon une étude d’OutSystems citée dans l’analyse, 94 % des organisations craignent que cette prolifération de l’IA n’augmente la complexité, la dette technique et les risques de sécurité.

On a déjà vécu ça avec le shadow IT, ces outils SaaS achetés en douce par les équipes. Mais l’agent sprawl est d’une autre nature, et c’est le point le plus important de toute l’analyse.

« La prolifération des agents est un risque d’identité et de responsabilité, pas du shadow IT. »

Atlassian, « Tackling agent sprawl across the enterprise » (traduction Corporate Mavericks)

Pourquoi cette distinction compte-t-elle autant ? Le shadow IT, ce sont des outils non approuvés qui stockent des données. On peut les repérer, par exemple grâce au trafic vers des fournisseurs inconnus. Un agent IA non maîtrisé, lui, est un acteur non approuvé qui utilise vos données et vos permissions pour agir en votre nom. Il opère comme un utilisateur autorisé, sur une infrastructure autorisée, avec des identifiants autorisés. Sauf qu’il le fait à une vitesse et à une échelle qu’aucun humain n’atteint.

Résultat : des questions opérationnelles basiques deviennent impossibles à trancher. Quels agents sont actifs ? Qui les possède ? À quelles données accèdent-ils ? Quelles actions déclenchent-ils ? Et surtout : que se passe-t-il quand l’un d’eux se trompe ?

Les 5 risques concrets de la prolifération des agents IA

L’analyse d’Atlassian identifie cinq conséquences qui remontent directement jusqu’au comité de direction. On les reprend ici, avec la lecture managériale qui va avec.

1. L’exposition des données. Un agent peut faire remonter ou déplacer des informations confidentielles d’une manière que personne n’avait anticipée. Le compte rendu du comité stratégique qui finit résumé dans un canal ouvert, par exemple.

2. Le risque d’identité et d’accès. Un agent hérite souvent de permissions trop larges, celles de la personne qui l’a créé, et se connecte à des systèmes sans les contrôles appropriés.

3. L’ambiguïté opérationnelle. Les équipes ne savent pas qui possède un agent, comment il prend ses décisions, ni comment l’arrêter. Quand son créateur quitte l’entreprise, l’agent, lui, continue de tourner.

4. Les coûts et la complexité non planifiés. Impossible de piloter la capacité, la dépendance aux fournisseurs ou le retour sur investissement quand l’activité des agents est éclatée dans tous les sens.

5. Des résultats inexacts et des décisions désalignées. Des agents déconnectés, sans contexte partagé, produisent des réponses contradictoires et des actions qui ne servent pas les objectifs de l’équipe.

Remarquez qu’aucun de ces risques n’est purement technique. Chacun renvoie à une question que le management sait (ou devrait savoir) poser : qui décide, qui possède, qui répond.

Chaque semaine, des analyses comme celle-ci sur l’IA et le management, sans jargon ni langue de bois.

Pourquoi interdire les agents IA ne marche pas

Face à ce tableau, le réflexe de beaucoup de directions est connu : tout bloquer. Un comité IA, une procédure de validation en sept étapes, une liste blanche de trois cas d’usage autorisés, et interdiction de créer des agents sans l’aval de la DSI. Sur le papier, le risque disparaît. Dans la réalité, il se déplace.

Atlassian le dit sans détour : restreindre l’IA sans garde-fous intelligents limite sa valeur, freine l’adoption et pousse l’expérimentation vers des outils non autorisés, où les collaborateurs collent du contexte sensible hors de toute supervision. Vous n’avez pas supprimé les agents, vous les avez rendus invisibles.

On retrouve exactement le mécanisme décrit dans notre article sur la bureaucratie en entreprise : chaque règle ajoutée pour se protéger d’un risque en crée un autre, plus diffus. Et comme pour le coût de l’IA en entreprise, rationner l’accès est souvent la pire façon de reprendre le contrôle.

L’excès inverse n’est pas meilleur. Donner à chaque agent une autonomie totale, un accès large et une exécution sans limite, c’est accepter de découvrir les dégâts après coup. Et verrouiller chaque action derrière une demande de confirmation du type « Dois-je faire ceci ? » produit une fatigue de l’approbation : les utilisateurs cliquent « oui » sans lire, et le contrôle devient une illusion. Les deux extrêmes ralentissent la création de valeur.

La règle d’or

Gouverner l’IA, pas bloquer l’IA.

La bonne gouvernance définit ce qu’un agent peut faire, avec quelles données, pour qui, et sous quelle revue. Elle pose un cadre clair, puis laisse les équipes avancer vite à l’intérieur. C’est exactement la logique de l’autonomie alignée : des limites explicites plutôt qu’un contrôle permanent.

Comment gouverner les agents IA sans tuer l’initiative : 6 principes

Voici ce qu’on retient de l’analyse d’Atlassian et des recommandations de Gartner, traduit en principes applicables par n’importe quelle organisation, quels que soient ses outils.

1. Tenir un registre vivant des agents

Vous ne pouvez pas gouverner ce que vous ne voyez pas. La visibilité est le premier signal de la gouvernance agentique. Il faut pouvoir répondre à tout moment à une question simple : combien d’agents existent, et combien sont réellement utilisés ? Un registre (même un simple tableau au départ) recense pour chaque agent son objectif, ses sources de données, ses outils, son propriétaire et sa fréquence d’utilisation. Les plateformes commencent à le proposer nativement, avec des indicateurs d’usage qui permettent de repérer les agents à nettoyer, à fusionner ou à restreindre.

2. Un propriétaire humain par agent, sans exception

C’est le principe le plus simple et le plus négligé. Chaque agent doit avoir un humain nommé qui en répond. Pas « l’équipe data », pas « la DSI » : une personne. Quand un agent se trompe, elle sait pourquoi, elle sait comment l’arrêter, et elle décide s’il faut le corriger ou le retirer. Un agent sans propriétaire est un agent à désactiver.

3. Calibrer l’autonomie selon le risque de l’action

Séparez les actions qu’on peut automatiser en confiance de celles qui exigent une supervision humaine. Ce tri évite à la fois l’autonomie aveugle et le harcèlement de confirmations. La matrice ci-dessous, inspirée des exemples d’Atlassian, donne une base de départ.

4. Hériter des permissions, puis les restreindre

Le socle minimal : un agent ne doit jamais voir plus que ce que la personne qui l’utilise a le droit de voir. Mais pour une gouvernance plus mature, il faut aller plus loin et définir des droits spécifiques par agent, limités à son rôle, plutôt que de s’appuyer sur l’accumulation de permissions d’un collaborateur présent depuis dix ans. Un agent de qualification de tickets n’a aucune raison d’accéder aux dossiers RH. Autre bonne pratique soulignée par Atlassian : faire apparaître l’agent comme contributeur à côté de la personne qui l’a lancé, et non à sa place. La traçabilité, c’est savoir qui a fait quoi, humain ou machine.

5. Donner du contexte, pas seulement des droits

C’est la phrase la plus juste de toute l’analyse : un agent non gouverné avec un contexte riche est risqué, mais un agent gouverné sans contexte est inutile. Dans une enquête Pulse menée auprès de plus de 1 000 travailleurs du savoir, seuls 12 % estiment que leur IA comprend l’entreprise mieux que ses collaborateurs les plus juniors. Autrement dit, la plupart des agents ont le niveau de compréhension d’un nouvel arrivé. Selon le rapport State of Teams 2026 d’Atlassian, les équipes dotées de fondations plus solides (objectifs clairs, connaissances partagées, priorités explicites) sont 7,3 fois plus susceptibles de déclarer un meilleur retour sur investissement de l’IA.

Traduction managériale : si vos objectifs ne sont écrits nulle part, si vos décisions vivent dans la tête de trois personnes et si votre documentation date de 2021, aucun agent ne fera de miracle. Il produira au mieux du contenu générique, au pire du workslop, ce contenu qui a l’air professionnel et ne sert à rien.

6. Faire le ménage et retirer les agents

Un agent n’est pas éternel. Prévoyez dès sa création comment il sera évalué et quand il sera retiré. Une revue trimestrielle du registre suffit souvent : on supprime les agents inutilisés, on fusionne les doublons (trois équipes ont presque toujours créé le même agent de synthèse de réunion), on restreint ceux qui ont des droits trop larges, et on prend le temps de vérifier les performances réelles de chacun (temps gagné, taux d’erreur, usage effectif). Les entreprises savent lancer des projets ; elles savent beaucoup moins bien les arrêter. Avec les agents, ce défaut coûte cher.

Le test anti-bullshit avant de créer un agent IA

Avant de déployer un nouvel agent dans votre équipe, posez ces sept questions. Si vous ne pouvez pas répondre à toutes, l’agent n’est pas prêt.

1. Quel problème précis résout-il, et comment le mesure-t-on aujourd’hui ?

2. Existe-t-il déjà un agent qui fait la même chose ailleurs dans l’entreprise ?

3. Qui en est le propriétaire nommé, et qui le remplace en son absence ?

4. À quelles données accède-t-il, et en a-t-il vraiment besoin ?

5. Quelles actions peut-il faire seul, et lesquelles exigent une validation ?

6. Comment l’arrête-t-on en cas de problème, et qui est prévenu ?

7. Comment saura-t-on, dans trois mois, s’il faut le garder, le modifier ou le supprimer ?

Si la réponse à la question 3 est « tout le monde », la vraie réponse est « personne ».

Comment créer un agent IA utile (sans ajouter au chaos)

Gouverner ne veut pas dire renoncer. Les meilleurs agents IA excellent sur des tâches répétitives, bien délimitées, où la valeur est facile à mesurer. C’est là qu’il faut commencer, avant de s’attaquer aux problèmes complexes.

Atlassian cite deux exemples instructifs. Le premier, un agent de revue de la qualité des tickets Jira : il analyse les tickets entrants, évalue s’ils contiennent assez de détails et publie un retour concret quand un ticket change de statut. Le périmètre est étroit, les règles sont claires, le bénéfice est visible. Le second, un assistant d’onboarding : il aide les nouveaux arrivants à monter en compétence en rassemblant la documentation utile, en présentant les normes de l’équipe et en les guidant dans les étapes obligatoires, sans jamais exposer d’informations auxquelles ils n’ont pas accès.

Le cas de DocuSign, présenté dans la même analyse, montre ce que donne une approche gouvernée à grande échelle : une création de tickets 75 % plus rapide (de 20 à 5 minutes environ par ticket), des séances d’affinage du backlog réduites de 2 heures à 30 minutes, plus de 10 heures récupérées chaque semaine par une équipe QA grâce à un agent spécialisé, et des agents standardisés déployés sur plus de 100 espaces Confluence avec une visibilité centralisée. Ces chiffres sont communiqués par l’éditeur, à prendre comme des ordres de grandeur, mais la logique est saine : peu d’agents, bien définis, partagés et suivis, plutôt que des centaines d’agents personnels qui font tous à peu près la même chose.

La méthode, si vous voulez créer des agents dans votre équipe :

• partez d’un irritant réel, observé, et non d’une démonstration impressionnante vue sur LinkedIn ;

• commencez par un premier agent en lecture seule, qui propose sans agir, et vérifiez la qualité de ses suggestions ;

• élargissez son autonomie action par action, à mesure que la confiance se construit ;

• documentez ses règles et ses sources pour que d’autres équipes puissent le réutiliser plutôt que le recréer ;

• fixez dès le départ les indicateurs qui diront s’il crée de la valeur (temps gagné, erreurs évitées, satisfaction des utilisateurs).

Le vrai sujet : qui répond quand un agent se trompe ?

L’analyse d’Atlassian conclut sur une idée que l’on partage entièrement : la gouvernance préserve le jugement humain là où il compte le plus. L’IA peut rassembler l’information, interpréter un large contexte et synthétiser vite. Les humains restent responsables des décisions qui demandent de la nuance, de l’expertise et une revue.

Pour un manager, cela change la nature du travail. Hier, vous étiez responsable de ce que faisait votre équipe. Demain, vous serez aussi responsable de ce que font les agents de votre équipe. « C’est l’IA qui a envoyé ce mail au client » ne sera jamais une excuse recevable, ni pour le client, ni pour la direction, ni pour un régulateur. Un agent n’a pas de responsabilité ; il n’a que des permissions.

Ce déplacement ressemble beaucoup à ce qu’on observe dans les organisations autogérées (voir notre article sur l’autogestion en entreprise) : plus vous distribuez l’autonomie, plus vous devez clarifier les rôles, les limites et la redevabilité. L’autonomie sans cadre n’est pas de la liberté, c’est du flou. Et comme on l’expliquait à propos de la collaboration humain-IA, les gains de vitesse individuels s’évaporent quand ils ne sont pas reliés au travail collectif.

Trois réflexes à adopter dès maintenant :

• Inscrivez les agents dans vos accords d’équipe. Qui peut en créer, pour quoi faire, avec quelle validation. Une page suffit.

• Parlez des agents dans vos rétrospectives. Quels agents nous aident vraiment ? Lesquels produisent du bruit ? Lesquels faut-il arrêter ?

• Traitez une erreur d’agent comme un incident. Sans chercher de coupable, mais en remontant aux causes : contexte manquant, droits trop larges, absence de validation sur une action à risque.

L’entreprise qui s’en sortira ne sera pas celle qui aura le plus d’agents IA. Ce sera celle qui pourra répondre, à tout moment, aux questions qui comptent : qu’est-ce qui existe, qui le possède, comment c’est utilisé, combien ça coûte, et est-ce que ça sert vraiment.

En résumé

• L’agent sprawl est un risque de responsabilité, pas un simple problème d’outillage.

• Interdire pousse les agents dans l’ombre ; tout autoriser revient à découvrir les dégâts après coup.

• Un registre, un propriétaire par agent, une autonomie calibrée selon le risque.

• Sans contexte partagé, un agent bien gouverné reste inutile.

• Un agent n’a que des permissions : la responsabilité reste humaine.

Questions fréquentes sur les agents IA en entreprise

Un agent IA est un système logiciel qui reçoit un objectif, utilise des outils (messagerie, CRM, gestion de tickets, documentation) et prend des décisions de manière autonome pour l’atteindre. Contrairement à un assistant IA qui se contente de répondre, un agent agit : il crée, modifie, envoie ou classe des éléments dans vos applications métier.L’agent sprawl désigne la prolifération non maîtrisée des agents IA dans une organisation : des agents créés par de nombreuses équipes, sans inventaire, sans propriétaire clair ni contrôle des accès. Gartner projette qu’une grande entreprise du Fortune 500 utilisera en moyenne plus de 150 000 agents d’ici 2028.Le shadow IT désigne des outils non approuvés qui stockent des données et que l’on peut souvent détecter. Un agent IA non maîtrisé est un acteur qui utilise vos données et vos permissions pour agir en votre nom, avec des identifiants autorisés. Il est donc plus difficile à repérer et ses actions ont des conséquences directes.Partez d’un besoin réel et délimité, nommez un propriétaire humain, limitez les accès aux seules données nécessaires, commencez en lecture seule, puis élargissez l’autonomie action par action. Les actions à risque (suppression, permissions, données personnelles ou financières, envoi externe) doivent rester soumises à une validation humaine.Non. Interdire ou trop restreindre pousse les collaborateurs vers des outils non autorisés, hors de toute supervision. Mieux vaut un cadre clair (registre, propriétaires, niveaux d’autonomie) à l’intérieur duquel les équipes peuvent expérimenter librement.Toujours un humain. Chaque agent doit avoir un propriétaire nommé qui en répond, sait comment l’arrêter et décide de le corriger ou de le retirer. Les erreurs d’agents se traitent comme des incidents : on cherche les causes (contexte manquant, droits trop larges, absence de validation), pas un coupable.

L’IA sans le bullshit, chaque semaine

Une newsletter pour les managers qui veulent tirer parti de l’IA sans perdre le contrôle de leur organisation. Zéro hype, que du concret.

Télétravail, présentiel, travail hybride : la guerre des jours de bureau cache une question que personne n’ose poser en comité de direction.

Et si le retour au bureau tenait moins à la productivité qu’à l’ego de ceux qui le décident ?

Le retour au bureau est devenu le grand sujet de 2026. Amazon, JPMorgan Chase, Meta, Disney : les grandes entreprises multiplient les mandats de présence, parfois cinq jours par semaine. Les arguments officiels sont toujours les mêmes : la culture d’entreprise, la cohésion d’équipe, la confiance, l’innovation qui naîtrait devant la machine à café.

Et si la vraie raison était ailleurs ? Une étude menée par Adam Grant, professeur de management à Wharton, avec les doctorantes Marissa Shandell et Courtney Elliott, avance une explication beaucoup moins flatteuse : chez les dirigeants, le trait qui prédit le mieux l’hostilité au télétravail, c’est le narcissisme.

Pas la méfiance. Pas la productivité. L’ego.

Chez Corporate Mavericks, on ne tape pas sur les patrons par principe. Mais cette recherche mérite qu’on s’y arrête, parce qu’elle oblige chaque manager à se poser une question inconfortable : quand j’exige que mon équipe revienne au bureau, est-ce pour elle, ou pour moi ?

Retour au bureau : ce que dit vraiment l’étude de Wharton

L’article scientifique s’intitule, sans détour, « Worship Me at the Office Altar: Why Narcissistic Leaders Resist Remote Work » (littéralement : « Vénérez-moi à l’autel du bureau »). Il est paru dans la revue Organizational Behavior and Human Decision Processes, et ses auteurs en ont tiré une tribune dans le New York Times qui a suscité plus de 2 000 commentaires. Preuve que le sujet touche un nerf.

Le point de départ des chercheurs est un paradoxe. Pendant la pandémie de covid-19, on estimait qu’entre 40 % et 70 % des salariés américains travaillaient entièrement à distance ou en mode hybride. Aujourd’hui, d’après la Réserve fédérale de Minneapolis, ce taux est retombé autour de 22 %. Pourtant, les données disponibles montraient que les salariés en télétravail maintenaient une productivité égale ou supérieure, avec une satisfaction plus élevée. Alors pourquoi ce retour en force du présentiel ?

Trois études, un même résultat

Pour répondre, l’équipe a conduit trois études complémentaires : une analyse d’archives, une enquête et une expérimentation. La première portait sur 259 PDG d’entreprises du classement Fortune 500. Les chercheurs ont croisé leurs prises de position publiques sur le travail à distance avec des indicateurs indirects d’ego :

• la place occupée par la photo du dirigeant dans le rapport annuel ;

• la taille de sa signature ;

• l’écart entre sa rémunération et celle du deuxième dirigeant le mieux payé de l’entreprise.

Le résultat est constant sur les trois études : les PDG les plus narcissiques résistent plus fortement au télétravail et avancent une palette plus large d’objections. Surtout, cette résistance s’explique par la recherche de pouvoir et de statut, pas par un manque de confiance envers les salariés.

« Le narcissisme est le seul trait qui prédisait de façon constante la résistance au télétravail. »

Marissa Shandell, Wharton (propos traduits de l’anglais)

Pourquoi un dirigeant narcissique a besoin de vous voir au bureau

L’explication est presque mécanique. Le leader narcissique se nourrit de signaux de domination : passer entre les bureaux, occuper la tête de table, imposer le silence d’un regard. Le lieu de travail physique est sa scène. Le télétravail lui retire son public.

En visio, il se retrouve face à une mosaïque de petites vignettes, souvent remplies de visages qui s’ennuient. Les chercheurs le résument avec un humour assez cruel dans leur tribune : les flatteries des collaborateurs n’ont pas tout à fait le même effet quand elles arrivent sur Slack.

C’est là que l’étude bouscule le discours dominant. Depuis la crise sanitaire, le débat sur le retour au travail en présentiel tourne autour de la confiance. Or, comme le souligne Marissa Shandell, nous vivons à l’ère de la surveillance numérique : si le seul enjeu était de vérifier que les gens travaillent, les outils existent déjà. Le besoin d’être vu, lui, ne se satisfait pas d’un tableau de bord.

On retrouve un schéma déjà décrit à propos du leadership positionnel : quand l’autorité repose sur le titre plutôt que sur la valeur apportée, elle a besoin de décor. Le bureau en est un.

Attention au raccourci

Les auteurs sont prudents, et nous aussi. La causalité va dans un seul sens : tous les dirigeants qui défendent la présence au bureau ne sont pas narcissiques. En revanche, les dirigeants narcissiques sont ceux qui y résistent le plus. Votre employeur peut avoir d’excellentes raisons de vouloir revenir au bureau certains jours. Simplement, s’il est incapable de les formuler autrement que par « parce que je l’ai décidé », le signal mérite attention.

Le test anti-bullshit d’un mandat de présence

Avant d’annoncer (ou de subir) un mandat de présence, posez ces cinq questions :

1. Quel problème précis la mesure doit-elle résoudre ? Intégration des juniors, coordination d’un projet critique, cohésion d’équipe dégradée ?

2. A-t-on mesuré ce problème avant de décider ?

3. Les dirigeants qui imposent la règle se l’appliquent-ils ?

4. Que fera-t-on concrètement de ces journées au bureau, au-delà d’enchaîner des visios depuis un open space ?

5. Comment saura-t-on, dans six mois, si la mesure a fonctionné ?

Si personne ne peut répondre, ce n’est pas une stratégie : c’est une préférence personnelle déguisée en politique RH.

Chaque semaine, des analyses comme celle-ci, sans jargon ni langue de bois.

Les vrais coûts d’un retour au bureau imposé

Un mandat de présence décidé pour de mauvaises raisons ne coûte pas rien. Il se paie en trois monnaies.

Les talents. Les chercheurs de Wharton le rappellent : la flexibilité est devenue un argument décisif pour recruter et fidéliser les meilleurs profils. Or les personnes les plus recherchées sont aussi celles qui ont le plus d’options ailleurs. Imposer le bureau tous les jours sans justification, c’est organiser soi-même une sélection à l’envers : partent ceux qui peuvent partir.

La confiance. Après des années où le travail à distance a montré qu’il fonctionnait, un ordre de retour sans explication envoie un message limpide : « on ne vous croit pas ». C’est exactement la logique que nous dénoncions dans notre article sur le micromanagement : le contrôle remplace la mission.

Le sens. Revenir sur site pour passer sa journée en visioconférence avec des collègues installés ailleurs, après une heure de temps de trajet, beaucoup de salariés connaissent. Cette expérience détruit précisément ce que la présence sur site prétendait protéger : le sentiment d’appartenance et le bien-être au travail.

Organiser le retour au bureau sans ego : 4 principes issus de la recherche

Bonne nouvelle : les auteurs ne s’arrêtent pas au diagnostic. Ils estiment que le travail hybride ne va pas disparaître et proposent quatre lignes directrices pour aider les managers à « mettre leur ego de côté » et à maîtriser l’art du management à distance. Voici comment on les traduit sur le terrain.

01

Des jours d’ancrage où tout le monde vient

Choisir collectivement un ou deux jours fixes où toute l’équipe est présente. C’est surtout précieux pour les nouveaux arrivants et les juniors, qui apprennent en observant et ont besoin de mentorat.

02

L’intensité bat la fréquence

Une journée bien conçue (atelier, résolution de problème, déjeuner d’équipe) crée plus de lien que cinq journées passées côte à côte, casque sur les oreilles. Venir doit valoir le trajet.

03

Pas de modèle unique

Les rôles diffèrent, les besoins aussi. Comme le note Courtney Elliott, les politiques d’entreprise sont rarement identiques pour tous : salaires et congés varient déjà. La présence peut varier aussi, si les règles sont explicites.

04

Le « quand » compte plus que le « où »

Si votre organisation ne peut pas offrir de jours à distance (production, accueil, terrain), elle peut offrir de l’autonomie sur les horaires. Un planning flexible redonne du contrôle sans changer de lieu.

Ce que ça donne concrètement pour un manager

Faire vivre ces principes, c’est d’abord changer de question. Au lieu de « combien de jours au bureau ? », demandez à votre équipe : « pour quoi faire, ensemble, au même endroit ? ». Listez les activités qui gagnent vraiment à se dérouler en face à face : l’intégration, les ateliers de conception, les rétrospectives difficiles, les moments de célébration. Le reste (travail de concentration, rédaction, une bonne partie des points d’avancement) peut souvent se faire à distance.

Ensuite, équiper les deux mondes. Un poste de travail ergonomique à la maison et des espaces de travail adaptés sur site (salles de réunion hybrides, zones calmes) évitent le pire des scénarios : se déplacer pour travailler moins bien qu’à la maison. Enfin, accepter un retour progressif et révisable : tester un modèle de travail hybride sur un trimestre, mesurer, ajuster avec l’équipe. C’est de l’agilité appliquée à l’environnement de travail.

Salarié : comment négocier du télétravail avec un boss qui a de l’ego

L’étude se termine sur un conseil étonnamment pragmatique. Face à un dirigeant narcissique, plaider frontalement pour le remote menace son pouvoir et son statut, donc renforce sa résistance. Les auteurs suggèrent plutôt de le consulter : lui demander son avis sur ce qui rendrait un arrangement hybride acceptable. En montrant du respect pour son autorité et ses réussites, on lui apporte la validation qu’il recherche, et sa résistance diminue.

Vu de Corporate Mavericks, ce conseil est à la fois efficace et un peu triste. Efficace, parce qu’il s’appuie sur la psychologie réelle des gens plutôt que sur celle qu’on aimerait qu’ils aient. Triste, parce qu’une entreprise où il faut flatter l’ego d’un dirigeant pour obtenir une organisation du travail rationnelle a un problème de gouvernance, pas un problème de lieu de travail. Les règles qui touchent le quotidien de centaines de personnes ne devraient pas dépendre de l’humeur d’une seule. C’est d’ailleurs un symptôme typique de la bureaucratie en entreprise : des décisions centralisées, prises loin du terrain, que personne n’ose questionner.

Concrètement, présentez votre demande comme une expérimentation : un périmètre clair, des résultats mesurables, une date de bilan. Vous ne demandez pas une faveur, vous proposez un test.

Le bureau n’est pas le problème.Le bureau transformé en scène pour l’ego du chef, si.

Et si on posait enfin la bonne question ?

Depuis le premier confinement, le débat télétravail contre présentiel est mal posé. Il oppose deux camps qui défendent un lieu, alors que la vraie question porte sur le pouvoir : qui décide de la façon dont le travail se fait, et sur quelle base ?

Les organisations qui s’en sortent le mieux ne sont ni « 100 % remote » ni « tous au bureau ». Ce sont celles qui laissent les équipes définir leurs propres règles dans un cadre clair, et qui jugent les gens sur ce qu’ils produisent plutôt que sur leur visibilité. Le retour au bureau peut être une excellente idée. À condition qu’il serve le travail, et pas le reflet du patron dans la vitre de la salle de réunion.

Source : Knowledge at Wharton, « Why Narcissistic Leaders Don’t Like Remote Work », d’après Shandell, Elliott et Grant, Organizational Behavior and Human Decision Processes, 2026.

Retour au bureau et télétravail : questions fréquentes

Les raisons officielles sont la culture d’entreprise, la cohésion, la collaboration et la confiance. L’étude de Wharton montre cependant que, chez les PDG, la résistance au télétravail est d’abord liée au narcissisme et au besoin de pouvoir et de statut, bien plus qu’à un manque de confiance envers les salariés.D’après les données citées par les chercheurs, les salariés à distance maintiennent une productivité égale ou supérieure, avec une satisfaction plus élevée. La productivité ne suffit donc pas à justifier un retour imposé.Il n’existe pas de chiffre magique. Le plus efficace est de fixer un ou deux jours d’ancrage communs, puis de laisser chaque équipe adapter le reste à ses activités réelles.En France, tout dépend de ce qui encadre votre travail depuis chez vous. S’il figure dans votre contrat ou un avenant, sa suppression suppose en principe votre accord. S’il découle d’une charte ou d’un accord collectif, ce sont les règles de révision de ce texte qui s’appliquent. Vérifiez vos documents et rapprochez-vous de vos représentants du personnel.Partir des activités qui gagnent à être faites ensemble, fixer des jours d’ancrage, miser sur l’intensité des rencontres plutôt que sur leur fréquence, bien équiper bureaux et domiciles, puis tester le modèle sur une période définie avant de l’ajuster avec l’équipe.Les chercheurs pensent que non : la flexibilité reste un levier clé pour attirer et fidéliser les talents. Ils s’attendent plutôt à ce que les entreprises expérimentent davantage pour trouver leur propre modèle.

Marre du management de façade ?

Une newsletter pour les managers qui préfèrent les résultats aux apparences. Zéro bullshit, que du concret.

Équipe pluridisciplinaire : pourquoi l’IA fabrique de faux polyvalents

Avec un assistant IA, chacun produit en dix minutes un livrable plausible dans un métier qu’il ne connaît pas. De loin, ça ressemble à de la pluridisciplinarité. De près, c’est une nouvelle dépendance, en plus discrète.

Mardi, revue de sprint. Le développeur back-end présente les maquettes de la nouvelle page (générées par IA), la chargée de marketing a écrit le script de migration de données (généré par IA), et le testeur a rédigé l’analyse juridique sur les cookies (générée par IA). Tout est propre, bien formaté, livré en avance. Le manager est ravi : « Enfin une vraie équipe pluridisciplinaire, tout le monde sait tout faire. » Trois semaines plus tard, la migration a corrompu une partie de la base clients, et personne dans la salle n’était capable de le voir venir.

Ce scénario n’a rien de caricatural. Il illustre un piège qui monte dans beaucoup d’organisations en 2026 : confondre l’accès à une réponse avec la compétence. Le coach agile Claude Aubry l’a formulé très clairement dans un article publié le 28 octobre 2026 sur les obstacles et antipatterns de la pluridisciplinarité (lire l’article original) : l’IA donne à chacun un accès superficiel à des domaines qu’il ne maîtrise pas, ce qui ressemble de l’extérieur à de la polyvalence.

Chez Corporate Mavericks, on voit ce glissement chez de nombreux clients. Les équipes gagnent en vitesse, perdent en capacité de jugement, et le management prend la première pour la seconde. Cet article remet les choses à plat : ce qu’est vraiment une équipe pluridisciplinaire, les quatre pièges qui la sabotent, ce que l’intelligence artificielle change, et comment manager ce type d’équipe sans se raconter d’histoires.

Qu’est-ce qu’une équipe pluridisciplinaire ? De la santé au travail en entreprise

Une équipe pluridisciplinaire réunit des professionnels aux compétences et aux expertises complémentaires, qui travaillent ensemble sur un objectif commun. L’intention n’est pas d’avoir « un peu de tout », mais de réduire les dépendances : l’équipe dispose en interne des savoir-faire nécessaires pour livrer de la valeur sans attendre en permanence un service extérieur, un expert rare ou une validation à trois étages.

Le concept vient de loin. Dans le secteur de la santé et le médico-social, l’équipe pluridisciplinaire est une évidence depuis des décennies : médecin généraliste, médecin spécialiste ou psychiatre, infirmier, kinésithérapeute, psychologue, assistant social ou ergothérapeute coordonnent leurs interventions autour du patient pour assurer une prise en charge globale, à l’hôpital comme en maison de santé. En santé au travail, la loi a même consacré ce fonctionnement : le médecin du travail anime une équipe où interviennent infirmiers, ergonomes, psychologues et conseillers en prévention, au service de la santé des salariés. Personne n’imagine qu’un infirmier remplace le médecin, ni que le personnel paramédical décide seul d’un diagnostic médical. Chacun garde son métier, et la qualité vient de la coordination, de la communication et d’un projet partagé.

Dans le monde de l’entreprise, l’agilité a popularisé la même idée. Le Scrum Guide décrit les équipes Scrum comme pluridisciplinaires : ensemble, leurs membres possèdent toutes les compétences nécessaires pour créer de la valeur à chaque sprint. Le mot important est ensemble. La pluridisciplinarité est une propriété du collectif, pas une exigence posée sur chaque individu.

Pluridisciplinaire, interdisciplinaire, transdisciplinaire : quelle différence ?

• Pluridisciplinaire : plusieurs disciplines travaillent côte à côte sur un même objectif, chacune avec ses méthodes. C’est le premier niveau de collaboration.

• Interdisciplinaire : les disciplines interagissent réellement, échangent leurs approches et construisent des solutions communes. Le travail en équipe devient une co-construction.

• Transdisciplinaire : les frontières entre disciplines s’estompent au profit d’une vision et d’un langage partagés autour du problème à résoudre.

En pratique, une bonne équipe agile glisse du pluridisciplinaire vers l’interdisciplinaire : on ne se contente pas de juxtaposer les métiers, on apprend à travailler les uns avec les autres. C’est justement cette progression que l’IA peut court-circuiter.

Les avantages d’une équipe pluridisciplinaire (quand elle est bien faite)

Les bénéfices d’une équipe pluridisciplinaire sont bien documentés, que ce soit dans les organisations agiles ou dans le soin :

• Moins d’attente. Les compétences sont dans l’équipe, donc le travail ne s’arrête pas à chaque passage de relais entre services.

• Des solutions plus complètes. La diversité des points de vue (technique, métier, design, juridique) fait émerger les angles morts avant la mise en production.

• Plus de robustesse. Quand une personne est absente, quelqu’un d’autre peut reprendre. Le fameux « facteur bus » remonte.

• Moins de silos. Une équipe organisée autour d’un produit ou d’un client casse naturellement les silos organisationnels qui ralentissent les grandes entreprises.

• Plus d’apprentissage. Chacun découvre le métier des autres, ce qui améliore la communication et la qualité des échanges.

Mais ces avantages reposent sur une condition rarement dite : chaque membre doit être capable de juger ce qui sort de l’équipe, au moins sur les sujets qui le concernent. Sans ce jugement, on n’a pas une équipe pluridisciplinaire. On a un groupe de personnes qui produisent beaucoup et ne vérifient rien.

Le vernis IA rend les erreurs invisibles

Sources : Atlassian Teamwork Lab (2026), BetterUp et Stanford via HBR (2025)

22 %

de chances en moins de repérer une erreur critique dans un document au rendu soigné

42 %

jugent moins fiable le collègue qui leur envoie un travail IA bâclé

62 %

seulement savaient ce qu’est un bon livrable avant d’en parler en équipe

Un livrable bien présenté endort la vigilance. Dans une équipe où plus personne ne maîtrise le domaine concerné, l’erreur traverse toutes les revues sans être vue.

Ces chiffres viennent d’une étude récente de l’équipe Teamwork Lab d’Atlassian (source). Sur 903 travailleurs du savoir américains, les relecteurs étaient 22 % moins susceptibles de repérer une faille critique dans la version « polie » d’un brouillon. Dans un atelier mené avec 31 salariés, seuls 62 % savaient au départ ce que leur équipe considérait comme un livrable de qualité, puis 100 % après une heure d’échange sur les standards. Leçon directe pour une équipe pluridisciplinaire : la qualité ne vient pas de l’outil, elle vient d’un standard partagé et de gens capables de l’appliquer.

Les 4 pièges qui sabotent une équipe pluridisciplinaire (et ce que l’IA aggrave)

Claude Aubry décompose la pluridisciplinarité en quatre pratiques : la polyspécialisation, le leadership émergent, la polyactivité et l’esprit critique. Pour chacune, il identifie un antipattern classique et un risque nouveau lié à l’IA. Voici notre lecture, côté management.

1. La polyspécialisation qui tourne au « tout le monde fait tout »

Ce qu’on observe : sous prétexte de pluridisciplinarité, on attend de chacun qu’il sache tout faire. Avec l’IA, l’illusion devient crédible : une personne produit un résultat plausible dans une discipline qu’elle ne connaît pas.

Le risque : plus personne n’a de point fort, la qualité baisse partout, et l’on croit avoir des généralistes alors qu’on a des personnes incapables de juger ce qu’elles livrent hors de leur domaine.

La parade : viser le recouvrement, c’est à dire deux personnes capables sur chaque discipline, et non l’uniformité. Et orienter l’ouverture vers une autre discipline vers la capacité de relire et corriger, pas seulement vers celle de produire. C’est le principe du profil en T : une expertise profonde, et une culture assez large pour dialoguer avec les autres métiers.

2. Le leadership émergent capté par le plus rapide

Ce qu’on observe : c’est toujours la même personne, la plus ancienne ou la plus à l’aise, qui prend la main sur tous les sujets. Version 2026 : celui qui manie le mieux l’IA produit vite des réponses sur tout.

Le risque : l’aisance avec l’outil passe pour une compétence métier. Les autres se mettent en retrait, et l’équipe redevient dépendante d’une seule personne, qui en plus ne connaît pas forcément le domaine.

La parade : reconnaître le leadership à la compréhension du domaine, pas à la vitesse de production. En rétrospective, regarder qui a pris la main sur quels sujets et inviter explicitement ceux qui ne la prennent jamais.

3. La polyactivité qui confond essayer et apprendre

Ce qu’on observe : pour éviter la monotonie, on fait tourner tout le monde sur toutes les tâches. L’IA rend encore plus facile de se lancer dans une activité qu’on n’a jamais faite.

Le risque : l’activité est traversée sans que la capacité reste dans l’équipe. Le travail est fait moins bien, plus lentement, et personne n’a vraiment appris.

La parade : laisser chacun choisir ce qu’il veut essayer, accepter que cet apprentissage coûte du temps sur le sprint, et faire accompagner chaque essai par un coéquipier capable de relire le résultat. Le binôme reste l’outil de montée en compétences le plus sous-estimé.

4. L’esprit critique délégué à la machine

Ce qu’on observe : pour préserver l’ambiance, on évite les sujets qui fâchent. Et l’IA répond avec assurance, en fournissant des arguments pour à peu près n’importe quelle position.

Le risque : la contradiction est soit confiée à l’outil, soit étouffée par une réponse qui paraît faire autorité. L’équipe cesse de délibérer et applique des choix que personne ne soutient vraiment.

La parade : traiter une réponse d’IA comme un avis de plus, à contester comme les autres, et exiger qu’une personne l’assume dans la discussion. Nous avons détaillé ce sujet dans notre article sur l’esprit critique face à l’IA, et sur les mécanismes de la pensée de groupe.

L’équipe confond l’accès à une réponse avec la compétence : elle croit réduire ses dépendances alors qu’elle en crée une nouvelle, sans esprit critique pour juger ce qui lui est proposé.Claude Aubry, « Pluridisciplinarité : obstacles, antipatterns et impact de l’IA » (2026)

Tu veux des équipes vraiment autonomes, pas juste rapides ?

Chaque semaine, on décortique ce qui marche vraiment en management, en organisation et en transformation. Zéro jargon, zéro bullshit.

Le piège d’avant l’IA : garder les anciens rôles dans la nouvelle équipe

Il serait injuste de tout mettre sur le dos de l’intelligence artificielle. Le premier antipattern que décrit Claude Aubry date d’avant ChatGPT : on monte une équipe « pluridisciplinaire », mais on y conserve les rôles anciens, architecte, développeur web, testeur, voire chef de projet déguisé en Scrum Master. Chacun reste dans son couloir, les passages de relais continuent, simplement à l’intérieur d’une même équipe au lieu de traverser l’organigramme.

Le risque, selon lui, est un retour probable à la culture du chef et de l’expert, au détriment de la robustesse. On a changé l’étiquette, pas le fonctionnement. La parade proposée est simple et exigeante : faire un travail collectif sur la définition des rôles. Qui décide de quoi ? Qui peut relire quoi ? Sur quelles disciplines sommes-nous fragiles ? Ces questions se traitent en équipe, pas dans un organigramme envoyé par les RH.

Le test anti-bullshit : pour chaque discipline critique de votre équipe (code, données, design, juridique, métier), combien de personnes sont capables de dire, sans IA, si un livrable est faux ? Si la réponse est « zéro » ou « une seule », vous n’avez pas une équipe pluridisciplinaire. Vous avez un goulet d’étranglement ou un angle mort.

Comment manager une équipe pluridisciplinaire à l’ère de l’IA : 6 leviers concrets

Voici ce que nous recommandons aux managers et aux coachs que nous accompagnons. Aucun de ces leviers ne consiste à interdire l’IA. Tous consistent à protéger la capacité de jugement collective.

1. Cartographier les compétences, pas les intitulés de poste. Une matrice simple (disciplines en colonnes, personnes en lignes, niveau « sait faire », « sait relire », « découvre ») rend visibles les zones où l’équipe n’a qu’un seul expert, ou aucun.

2. Viser deux relecteurs compétents par discipline critique. C’est l’objectif de recouvrement. Il guide les choix de formation et de recrutement bien mieux qu’un vague « tout le monde doit monter en compétences ».

3. Rendre l’usage de l’IA visible. Indiquer quand un livrable a été produit avec un assistant, et par qui il a été relu. L’objectif n’est pas de culpabiliser, mais de savoir où concentrer la vérification.

4. Écrire ensemble les standards de qualité. L’atelier d’une heure mené par Atlassian a suffi à faire passer de 62 % à 100 % la part de salariés qui savent ce qu’est un bon livrable. Une définition de « terminé » partagée vaut plus que n’importe quel outil.

5. Payer le coût de l’apprentissage. Le binômage, la programmation en binôme ou la relecture croisée prennent du temps sur le sprint. C’est un investissement dans la robustesse, pas une perte de productivité.

6. Faire parler le domaine avant l’outil. En réunion de conception, demander d’abord ce que pensent les personnes qui connaissent le métier, puis seulement ce que propose l’IA. L’ordre change tout. Une équipe qui fonctionne ainsi progresse naturellement vers plus d’autogestion.

Qui compose une équipe pluridisciplinaire efficace, et quel rôle pour chaque membre ?

Il n’existe pas de composition universelle. Une équipe produit numérique réunit souvent développeurs, designer, product owner, spécialiste des données et expert métier. Une équipe de soins réunit médecins, infirmiers, aides-soignants, psychologue et travailleur social, avec un cadre de santé qui coordonne. Dans le secteur social, l’équipe accompagne l’autonomie des personnes en croisant éducateurs, conseillers et intervenants spécialisés selon les besoins et les troubles rencontrés. Dans tous les cas, trois critères font la différence :

• Une taille raisonnable : au-delà de neuf ou dix personnes, la coordination prend le pas sur le travail et les échanges se fragmentent.

• Une mission claire et partagée : sans objectif commun, la diversité des profils produit des tensions plutôt que de la complémentarité.

• De la stabilité : une équipe recomposée tous les trois mois n’a jamais le temps de construire la confiance ni les compétences croisées qui font sa valeur.

Le rôle du manager n’est donc pas de distribuer les tâches entre experts, mais de créer les conditions pour que l’équipe s’organise, se coordonne et apprenne. C’est un changement de posture plus qu’un changement d’organigramme.

L’équipe pluridisciplinaire en trois phrases

C’est une propriété du collectif : l’équipe possède ensemble les compétences nécessaires, personne n’a à tout savoir faire.

L’IA crée de faux polyvalents : produire un livrable plausible n’est pas la même chose que savoir juger s’il est juste.

Le bon objectif est le recouvrement : deux personnes capables de relire chaque discipline critique, des standards de qualité écrits ensemble, et un usage de l’IA visible.

Vous voulez faire le point sur la façon dont vos équipes travaillent vraiment avec l’IA ? Réservez un appel stratégique avec Corporate Mavericks.

FAQ : l'équipe pluridisciplinaire

C’est une équipe qui réunit des professionnels aux compétences complémentaires (technique, métier, design, données, soin, social selon le secteur) autour d’un objectif commun. Son intérêt est de réduire les dépendances extérieures : ensemble, ses membres disposent des savoir-faire nécessaires pour livrer de la valeur.Dans une équipe pluridisciplinaire, les disciplines travaillent côte à côte sur un même objectif. Dans une approche interdisciplinaire, elles interagissent réellement et construisent des solutions communes. La transdisciplinarité va plus loin en effaçant les frontières entre disciplines au profit d’une vision partagée.Moins d’attente entre services, des solutions plus complètes grâce à la diversité des points de vue, une meilleure robustesse en cas d’absence, moins de silos et davantage d’apprentissage mutuel. Ces avantages supposent que chaque discipline critique soit maîtrisée par au moins deux personnes.En santé, c’est un ensemble de professionnels (médecin généraliste ou spécialiste, infirmier, kinésithérapeute, psychologue, assistant social, ergothérapeute) qui coordonnent leurs interventions autour du patient, à l’hôpital, en maison de santé ou en service de santé au travail. Chacun garde son expertise, et la qualité du suivi vient de la coordination et d’un projet de soins partagé, souvent discuté lors d’un staff pluridisciplinaire.En cartographiant les compétences réelles, en visant deux relecteurs compétents par discipline critique, en écrivant ensemble des standards de qualité, en finançant le temps d’apprentissage (binômes, relecture croisée) et en reconnaissant le leadership à la compréhension du domaine plutôt qu’à la vitesse de production.En apparence seulement. L’IA permet à chacun de produire un résultat plausible hors de son domaine, mais pas de juger s’il est correct. Sans experts capables de relire, l’équipe crée une nouvelle dépendance à l’outil. L’IA est utile si elle sert à apprendre et à relire, pas à remplacer la compétence.Ils dépendent du secteur : en santé, médecin, infirmier, psychologue ou assistant social ; en produit numérique, développeurs, designer, product owner, expert données et expert métier. L’essentiel est de définir les rôles collectivement, en précisant qui décide, qui produit et qui peut relire chaque type de travail.

Des équipes qui savent juger, pas seulement produire

Reçois chaque semaine nos analyses sur le management, le leadership et la transformation, sans jargon ni bullshit.

Klarna n'est pas un cas isolé. Gartner prévoit que plus de 40 % des projets d'IA agentique seront annulés d'ici fin 2027, pour trois raisons : des coûts qui dérapent, une valeur métier floue et un contrôle des risques insuffisant (Gartner, juin 2025). Le problème n'est presque jamais le modèle. C'est la décision de départ : on confie à un agent autonome un travail qui demandait un simple workflow, sans critère de succès, sans garde-fou et sans propriétaire. Voici ce que cette édition vous apporte :

• Les quatre niveaux d'autonomie (assistant, workflow, agent supervisé, agent autonome) et la règle pour choisir le plus bas qui suffit, à partir des recommandations publiques d'Anthropic et de l'OWASP.

• Ce que disent vraiment les données sur les agents en production : enquête McKinsey 2026, benchmark académique TheAgentCompany, décision de justice Air Canada.

• Le livrable : la scorecard Go/No-Go Agent IA, trois questions éliminatoires, huit critères notés, une règle de décision et des critères d'arrêt, utilisable telle quelle en comité.

• Un canevas d'atelier de 90 minutes pour trier votre portefeuille de projets, et un plan d'action à 7, 30 et 90 jours.

La suite est réservée aux membres de The Mavericks Club. Si vous pilotez un portefeuille IA, ou si l'on vous demande « un agent » pour le trimestre prochain, rejoignez le Club pour lire l'analyse complète et récupérer la scorecard.

Read more

Sentiment d’appartenance au travail : pourquoi vos afterworks ne retiennent personne

Les trois quarts des salariés ont déjà quitté un job parce qu’ils ne s’y sentaient pas à leur place. Le problème ne se règle ni avec un baby-foot ni avec une charte de valeurs. Il se règle dans le quotidien du management.

Vendredi, 18h30. L’afterwork trimestriel bat son plein : pizzas, playlist, discours du directeur sur « la grande famille ». Lundi matin, la même équipe retrouve un manager qui change les priorités sans explication, des réussites que personne ne remarque et des réunions où l’on évite soigneusement de dire ce qu’on pense. Deux mois plus tard, deux personnes démissionnent. Au pot de départ, tout le monde dit que « l’ambiance était pourtant super ».

Le sentiment d’appartenance au travail est devenu l’un des sujets RH les plus discutés de 2026, et pour cause : il pèse directement sur la rétention, l’engagement et la marque employeur. Mais il reste aussi l’un des plus mal compris. Beaucoup d’entreprises le confondent avec la convivialité, alors qu’il se joue ailleurs : dans la reconnaissance, le sens, la clarté du management et la possibilité d’être soi-même.

C’est ce que montre le rapport ANCRAGES de Welcome to the Jungle, dont les principaux chiffres ont été repris dans un article publié le 26 octobre 2026 (lire l’article original). Les données sont claires, et franchement peu flatteuses pour les directions qui misent tout sur l’événementiel.

Chez Corporate Mavericks, on le constate chez presque tous nos clients : les entreprises dépensent des fortunes en cohésion d’équipe festive, puis s’étonnent du turn-over. Le vrai levier est moins spectaculaire, et beaucoup plus exigeant.

Qu’est-ce que le sentiment d’appartenance en entreprise, vraiment ?

Le besoin d’appartenance n’a rien d’une mode managériale. Dans la pyramide de Maslow, il arrive juste après les besoins physiologiques et de sécurité : l’être humain a besoin de se sentir membre d’un groupe social qui l’accepte. Au travail, ce besoin ne disparaît pas parce qu’on signe un contrat. Il se déplace simplement vers l’équipe, le manager et l’organisation.

Concrètement, le sentiment d’appartenance, c’est la conviction d’un collaborateur qu’il fait partie intégrante du collectif : que sa présence compte, que sa contribution est vue, qu’il peut parler sans se censurer et que, si ça coince, quelqu’un sera là. Ce n’est pas la même chose que la satisfaction au travail (on peut être satisfait de son salaire et se sentir étranger à son équipe), ni que l’engagement (on peut se donner à fond tout en se sentant de passage).

Le psychologue du travail Adrien Chignard, cité dans le rapport, parle d’un besoin d’affiliation sociale : être apprécié pour ce qu’on est, sans subir de regard discriminant. Autrement dit, il ne s’agit pas d’être aimé de tout le monde, mais de pouvoir exister dans le groupe sans avoir à s’effacer.

Les chiffres qui devraient réveiller votre DRH

Source : rapport ANCRAGES, Welcome to the Jungle (2026)

75,5 %

des salariés ont déjà quitté un emploi parce qu’ils ne s’y sentaient pas à leur place

5,28/10

score moyen du sentiment d’appartenance des salariés en poste

71,1 %

citent un management peu clair, distant ou irrespectueux comme facteur d’exclusion

Un score de 5,28 sur 10, ce n’est pas une catastrophe. Ce n’est pas un atout non plus. C’est une organisation où chaque employé garde un pied dehors, et où la moindre offre concurrente devient une vraie tentation.

Ce qui frappe dans ces chiffres, c’est l’écart entre ce que les entreprises financent et ce que les salariés décrivent. Aucun des facteurs les plus cités ne parle d’événements, de locaux ou d’avantages. Ils parlent tous de la relation de travail au quotidien. C’est une bonne nouvelle : ce sont des leviers que n’importe quel manager peut actionner dès demain, sans budget.

Les 5 piliers du sentiment d’appartenance (et ce que le manager peut y faire)

Le rapport ANCRAGES permet d’identifier cinq dimensions qui reviennent dans la définition que les salariés donnent de l’appartenance. Pour chacune, voici ce qu’elle signifie et ce qui la construit, ou la détruit, sur le terrain.

1. La reconnaissance, pas le « merci à tous » de fin de réunion

C’est le premier élément cité : 65,5 % des salariés définissent le sentiment d’appartenance avant tout par le fait d’être reconnus et valorisés. À l’inverse, le manque de reconnaissance est le deuxième facteur d’exclusion (47,6 %). La reconnaissance utile n’est pas un discours annuel. C’est confier un dossier important parce qu’on connaît les compétences de la personne, lui demander son avis avant une décision qui la concerne, et surtout en tenir compte. C’est aussi refuser que les réussites soient captées par celui qui se vend le mieux.

2. L’utilité : savoir à quoi sert son travail

60,5 % des salariés associent l’appartenance au fait de se sentir utile et de contribuer à un projet commun. Le Deloitte Global Gen Z and Millennial Survey 2026 va dans le même sens : 97 % des millennials estiment que le sens au travail contribue à leur satisfaction et à leur bien-être. Inutile de promettre de changer le monde. Il suffit que chacun sache pourquoi il prépare ce document, à qui il servira et ce qu’il permet de débloquer. Une équipe qui exécute des décisions que personne n’explique finit par cocher des cases, pas par s’attacher à un projet.

3. Le collectif : une équipe sur laquelle s’appuyer

54,8 % des salariés relient l’appartenance au fait de faire partie d’une équipe, et 43,6 % citent les relations difficiles comme facteur d’exclusion. Attention au contresens : il ne s’agit pas de devenir amis ou de déjeuner ensemble tous les midis. Il s’agit de pouvoir demander de l’aide sans avoir l’impression de déranger, et de savoir que les autres seront là quand ça se complique. L’entraide se construit dans les interactions du quotidien, pas dans les discours sur la cohésion.

4. Pouvoir être soi-même, sans jouer un rôle

47,8 % des salariés incluent la possibilité d’être soi-même dans leur définition de l’appartenance. C’est le pilier le plus subtil, parce qu’il est invisible de l’extérieur : une personne peut être performante, appréciée et bien évaluée tout en filtrant chaque phrase par peur des conséquences. Cette vigilance permanente épuise. Elle est directement liée à la sécurité psychologique au travail : si exprimer un désaccord coûte cher, les gens se taisent, puis s’en vont.

5. Un management clair, pas ambivalent

C’est le levier le plus puissant, dans les deux sens. 63 % des salariés citent un management clair, respectueux et bienveillant comme facteur majeur d’appartenance. Et 71,1 % désignent un management peu clair, distant ou irrespectueux comme facteur d’exclusion, le chiffre le plus élevé de toute la série. Un bon manager n’est pas celui qui ne fait jamais de remarques. C’est celui qui pose un cadre, dit ce qui va et ce qui ne va pas, et ne laisse pas son équipe deviner ce qu’il attend.

Un management ambivalent, qui dit une chose puis son contraire, est particulièrement nocif car il plonge les équipes dans l’incertitude.Adrien Chignard, psychologue du travail, cité dans le rapport ANCRAGES

Tu veux des équipes où les gens restent par envie, pas par inertie ?

Chaque semaine, on décortique ce qui marche vraiment en management et en culture d’entreprise. Zéro jargon, zéro bullshit.

Pourquoi les afterworks et les chartes de valeurs ne suffisent pas

Quand une direction veut améliorer le sentiment d’appartenance, le réflexe est presque toujours le même : un séminaire, un afterwork, une nouvelle charte, parfois un « chief happiness officer ». Ces initiatives ne sont pas inutiles. Elles sont simplement sans effet si le quotidien les contredit.

Le coach agile Claude Aubry décrit très bien cet antipattern dans un article récent sur la coopération : sous prétexte de bonne ambiance, on organise des activités de cohésion où l’on ne parle jamais du travail. Résultat, le ressenti réel (fatigue, désaccords, frustration) n’a aucun endroit où s’exprimer. Même logique pour la charte de valeurs affichée dans le hall et que personne ne relit : quand l’écart avec les pratiques devient visible, elle nourrit le cynisme au lieu de l’attachement.

Nous avons déjà montré que la plupart des séminaires d’équipe ne changent rien quand ils ne sont pas reliés au travail réel. Le sentiment d’appartenance suit la même règle. Les gens jugent la culture d’entreprise sur des moments concrets, comme la façon dont on coupe la parole en réunion, pas sur les slogans.

Le test anti-bullshit : si votre plan d’action pour renforcer l’appartenance tient entièrement dans le budget événementiel, il ne traite aucun des cinq facteurs cités par les salariés. Reconnaissance, utilité, entraide, authenticité, clarté du management : rien de tout cela ne s’achète chez un traiteur.

IA et télétravail : les nouveaux risques pour l’appartenance

Deux évolutions récentes fragilisent le lien collectif sans que personne ne le décide vraiment. La première est connue : avec le télétravail et les collaborateurs distants, les échanges informels se raréfient, et c’est précisément là que se construit une bonne part de l’entraide. La seconde est plus récente et beaucoup moins discutée : l’IA générative.

Quand un assistant IA répond instantanément à la question qu’on aurait posée à un collègue, on gagne du temps. Mais on perd aussi une occasion de don et de contre-don, cette réciprocité qui fait qu’un groupe devient une équipe. Claude Aubry le formule ainsi :

L’entraide s’étiole. Chacun s’adresse d’abord à son assistant et l’équipe perd les échanges informels qui la constituent en tant qu’équipe.Claude Aubry, « Coopération : obstacles, antipatterns et impact de l’IA » (2026)

La même logique s’applique à la reconnaissance : un message de félicitations généré par IA, que personne n’a vraiment écrit, ne produit aucun sentiment d’être vu. La parade n’est pas de bannir l’IA, mais de préserver des moments de travail réellement commun (binômes, revues, résolution de problèmes à plusieurs), de rendre l’usage de l’IA visible plutôt que solitaire, et de garder entre humains tout ce qui touche au ressenti.

Comment développer le sentiment d’appartenance : 7 leviers concrets pour managers

Voici ce que nous recommandons aux managers et aux équipes RH que nous accompagnons. Aucun de ces leviers ne demande de budget. Tous demandent de la constance.

1. Rendre la reconnaissance précise. Remplacer le « bravo l’équipe » par une phrase qui nomme la personne, ce qu’elle a fait et l’effet que ça a eu. Une reconnaissance spécifique vaut dix remerciements génériques.

2. Relier chaque mission à son impact. Pour chaque projet, expliciter pour qui on travaille et ce que ça débloque. Partager les retours clients ou utilisateurs avec ceux qui ont fait le travail, pas seulement avec le comité de direction.

3. Consulter avant de décider. Demander l’avis des personnes concernées avant une décision qui touche leur travail, puis leur dire ce qu’on a retenu et pourquoi. Consulter sans tenir compte des réponses est pire que ne pas consulter.

4. Rendre les besoins d’aide visibles. Un tableau d’obstacles partagé, des points courts où chacun dit ce qui le bloque : l’entraide devient normale au lieu d’être un aveu de faiblesse.

5. Protéger le désaccord. Faire parler le manager en dernier, remercier explicitement la personne qui contredit, ne jamais sanctionner, même subtilement, une mauvaise nouvelle apportée de bonne foi.

6. Tenir une ligne claire. Écrire les priorités, les annoncer quand elles changent et expliquer pourquoi. L’ambivalence est le premier poison de l’appartenance.

7. Stabiliser les équipes. Une équipe recomposée tous les trois mois n’a jamais le temps de créer de la confiance. Traiter les personnes comme des ressources interchangeables détruit l’attachement plus vite que n’importe quel plan ne le construit.

Comment évaluer le sentiment d’appartenance sans tomber dans le baromètre gadget

Le sentiment d’appartenance est un ressenti, mais il laisse des traces mesurables. Côté RH, quelques indicateurs donnent une première image : le turn-over volontaire (surtout dans les 12 premiers mois), le taux de rétention des talents par équipe, les motifs exprimés en entretien de départ, ou encore la proportion de collaborateurs prêts à recommander l’entreprise comme employeur. Une forte disparité entre équipes est souvent le signe d’un problème de management local, pas d’un problème de culture globale.

Pour aller plus loin, rien ne remplace des questions simples posées régulièrement, et dont on partage les résultats. Le rapport propose d’ailleurs une grille utile, transposable en entretien individuel : est-ce que ce que je fais est vu ? Est-ce que je comprends en quoi mon travail compte ? Est-ce que je me sens soutenu quand ça coince ? Est-ce que je peux exprimer un désaccord sans craindre les conséquences ? Est-ce que mon manager me donne des retours clairs, même quand c’est difficile ?

Dans une stratégie RH cohérente, ce suivi couvre tout le cycle de vie du collaborateur : l’intégration (c’est là que se joue la première impression d’appartenance), les moments de changement (réorganisation, nouveau manager, passage en télétravail) et le départ. Il permet aussi de repérer les silos où une équipe fonctionne en vase clos, coupée des objectifs communs. Un salarié qui se sent à sa place devient naturellement un ambassadeur de l’entreprise, bien plus crédible que n’importe quelle campagne de marque employeur. Et chaque collaborateur qui ne s’y sent plus envoie, lui aussi, un signal à l’extérieur.

Le piège, c’est le sondage annuel dont personne ne voit jamais la suite. Mesurer sans agir envoie un message limpide aux employés : votre avis ne compte pas. Exactement l’inverse de ce qu’on cherche à construire.

Le sentiment d’appartenance en trois phrases

Ce n’est pas de la convivialité : les salariés définissent l’appartenance par la reconnaissance, l’utilité, l’entraide, l’authenticité et la clarté du management.

Le manager est le levier numéro un, dans les deux sens : 63 % y voient un facteur d’appartenance, 71,1 % un facteur d’exclusion quand il est flou ou distant.

Les risques sont nouveaux : télétravail et IA générative peuvent éroder l’entraide sans bruit. Il faut protéger délibérément les moments de travail commun.

Vous voulez faire le point sur la culture réelle de vos équipes ? Réservez un appel stratégique avec Corporate Mavericks.

FAQ : le sentiment d'appartenance au travail

Parce qu’il pèse directement sur la rétention et la fidélisation. Selon le rapport ANCRAGES de Welcome to the Jungle, 75,5 % des salariés ont déjà quitté un emploi parce qu’ils ne s’y sentaient pas à leur place. Un fort sentiment d’appartenance favorise aussi l’engagement, la coopération et la qualité de vie au travail.En agissant sur le quotidien plutôt que sur l’événementiel : une reconnaissance précise, des missions reliées à leur impact, une consultation réelle avant les décisions, une entraide rendue visible, la protection du désaccord, un management clair et des équipes stables.Être régulièrement coupé ou ignoré en réunion, voir ses idées reprises par d’autres sans attribution, recevoir des consignes contradictoires sans explication, être exclu des décisions qui concernent son propre travail, ou subir des remarques sur sa personne plutôt que sur son travail.Le salarié fait le minimum, ne propose plus d’idées, se tait en réunion, ne s’intéresse plus aux résultats de l’équipe et parle de l’entreprise à la troisième personne. Ce désengagement silencieux précède souvent une démission et signale une perte du sentiment d’appartenance.Croisez des indicateurs RH (turn-over volontaire, rétention par équipe, motifs de départ, recommandation de l’employeur) avec des questions régulières sur la reconnaissance, le sens, le soutien de l’équipe et la liberté d’exprimer un désaccord. Surtout, partagez les résultats et agissez : mesurer sans suite détruit la confiance.Pas automatiquement, mais il réduit les échanges informels qui nourrissent l’entraide. Avec des collaborateurs distants, il faut organiser délibérément des moments de travail commun, rendre les demandes d’aide visibles et veiller à ce que la reconnaissance ne profite pas seulement aux personnes présentes au bureau.

Des équipes où l’on reste par choix

Reçois chaque semaine nos analyses sur le management, le leadership et la transformation, sans jargon ni bullshit.

Couper la parole en réunion : ce que les interruptions révèlent vraiment de votre culture

Vos valeurs sont affichées dans le hall d’accueil. Votre vraie culture, elle, se joue en réunion, à la seconde où quelqu’un se fait couper la parole et où personne ne réagit. Une recherche publiée par MIT Sloan Management Review en fait un indicateur culturel à part entière.

Comité de pilotage, mardi 10h. Une cheffe de projet commence à expliquer pourquoi le planning ne tiendra pas. Au bout de huit secondes, un directeur l’interrompt : « Oui, enfin, on a compris, l’important c’est la date. » La discussion repart ailleurs. Personne ne dit rien. Trois semaines plus tard, le planning dérape exactement comme elle l’avait annoncé, et tout le monde s’étonne.

Couper la parole en réunion passe pour un détail de savoir-vivre, une affaire de tempérament ou un effet secondaire du rythme. C’est pourtant l’un des signaux les plus lisibles de la culture réelle d’une organisation. C’est la thèse d’un article publié le 27 octobre 2026 dans MIT Sloan Management Review par Ghulam Murtaza (Kedge Business School), Benjamin Laker (Henley Business School), Rahman Khan (Paris School of Business) et Athar Hameed (Westminster International University in Tashkent) (lire l’article original, en anglais).

Leur constat est simple et dérangeant : les dirigeants parlent de culture avec des mots abstraits (valeurs, confiance, appartenance), alors que les salariés, eux, jugent la culture sur des moments. Et parmi ces moments, l’interruption est l’un des plus révélateurs. Qui se fait couper ? Qui va au bout de sa phrase ? Et surtout, que se passe-t-il juste après ?

Chez Corporate Mavericks, on l’observe chez presque tous nos clients : les entreprises investissent dans des baromètres d’engagement sophistiqués, mais personne ne regarde ce qui se passe concrètement dans une réunion de 45 minutes. C’est là que l’équipe apprend qui compte vraiment.

Pourquoi couper la parole en réunion est un signal culturel (et pas un trait de caractère)

Les interruptions sont rarement mesurées dans les enquêtes de culture ou les tableaux de bord d’engagement. On les met sur le compte d’un style de conversation, d’un conflit de personnalités ou de l’urgence. Les chercheurs montrent pourtant qu’elles sont l’un des indices les plus clairs que les salariés utilisent pour savoir quelles voix font autorité, quel jugement est jugé fiable, et quelle présence doit être sans cesse renégociée.

Les salariés ne parlaient pas de la culture dans le langage abstrait des dirigeants, mais en termes de moments. Et les moments d’interruption étaient parmi les plus révélateurs.Murtaza, Laker, Khan et Hameed, MIT Sloan Management Review (traduction libre)

Pour arriver à cette conclusion, l’équipe a mené des entretiens approfondis avec des dirigeants qui avaient vécu ou observé des interruptions au travail, puis analysé des enregistrements de réunions et des observations de terrain, en codant les tours de parole, les interruptions et la reprise des idées. Leur grille de lecture tient en une phrase : quand quelqu’un est interrompu, trois choses se produisent en même temps.

• Sa contribution est écourtée : l’idée n’est jamais exposée en entier, donc jamais vraiment évaluée.

• La direction de la discussion change : celui qui interrompt reprend la main sur le sujet.

• Un jugement implicite est rendu devant tout le groupe sur qui mérite de terminer sa phrase.

C’est ce troisième point qui fait de l’interruption un fait culturel. Toute l’équipe assiste à la scène. Tout le monde enregistre le verdict. Et tout le monde ajuste son comportement pour la prochaine fois.

Est-ce que couper la parole est un manque de respect ?

Pas forcément, et c’est là que l’article évite le moralisme facile. Les auteurs le disent clairement : les interruptions ne sont pas problématiques par nature. Dans certains contextes, elles traduisent de l’énergie, de l’urgence ou une vraie collaboration. Deux personnes qui construisent une idée ensemble se coupent sans arrêt, et c’est très bien.

Ce qui compte, c’est la répartition et la suite. Il faut distinguer deux familles d’interruptions :

• L’interruption coopérative : on cherche à rebondir pour compléter, on précise un chiffre, on montre son accord. Elle prolonge l’idée de l’autre et lui rend vite la parole.

• L’interruption de domination : on coupe pour changer de sujet, contredire avant d’avoir entendu, ou reprendre la main. Elle installe un rapport de force et ferme la discussion.

Le vrai problème apparaît quand les interruptions se concentrent toujours sur les mêmes personnes. Les chercheurs observent justement qu’elles étaient réparties de façon inégale dans les contextes étudiés. Quand ce sont systématiquement les plus juniors, les profils minoritaires ou les personnes plus réservées qui se font couper, l’équipe ne voit plus un style de conversation : elle voit une hiérarchie officieuse.

Ce que coûte une interruption que personne ne répare

L’article MIT Sloan s’appuie sur une étude des mêmes chercheurs publiée en 2026 dans le Journal of Business Ethics, consacrée aux micro-agressions vécues par des salariées. Sur deux expériences par vignettes et une enquête en deux temps (775 participantes au total), le résultat est net : les petits actes d’exclusion érodent le sentiment d’appropriation psychologique, ce sentiment que « c’est aussi mon projet, mon entreprise », et augmentent les comportements d’opposition au travail.

Concrètement, une personne qu’on coupe régulièrement ne se bat pas indéfiniment pour reprendre la parole. Elle finit par s’autocensurer. Elle prépare moins ses interventions, garde ses objections pour la machine à café, et se désengage du résultat. Vous ne perdez pas seulement une phrase : vous perdez l’information qu’elle contenait.

C’est aussi le terreau de la pensée de groupe : quand seules les voix dominantes vont au bout de leur raisonnement, le groupe confond l’absence d’objection avec le consensus. Les travaux d’Anita Woolley et de ses collègues, publiés dans Science en 2010, ont d’ailleurs montré que l’intelligence collective d’un groupe dépend davantage de l’équilibre des tours de parole et de la sensibilité sociale de ses membres que du QI de ses meilleurs éléments.

Que signifie le fait qu’une personne coupe toujours la parole ?

Avant de coller une étiquette sur le collègue qui coupe la parole à tout le monde, il vaut mieux comprendre ce qui se joue. Les causes sont multiples, et elles n’appellent pas la même réponse.

Le statut et le pouvoir

Plus on est haut dans la hiérarchie, plus on s’autorise à interrompre, souvent sans même s’en rendre compte. Le manager qui « recadre » vite pense gagner du temps. En réalité, il envoie le message que sa parole vaut plus que celle des autres, et c’est exactement ce que l’équipe retient.

L’enthousiasme et la peur d’oublier son idée

Beaucoup de personnes interrompent parce qu’une idée surgit et qu’elles craignent de perdre le fil. Chez certains profils, notamment les personnes avec un TDAH, l’impulsivité verbale n’a rien d’une volonté de dominer : c’est un fonctionnement cognitif. La réponse n’est pas la sanction, mais des outils (noter son idée, attendre le bon moment) et un cadre clair pour toute l’équipe.

Une culture qui récompense le plus rapide

Dans beaucoup d’organisations, la réunion est implicitement un concours de réactivité. Celui qui parle vite et fort passe pour leader, celui qui réfléchit avant de répondre passe pour hésitant. Si c’est votre cas, inutile de demander aux gens d’être plus polis : c’est le système qu’il faut changer. Et si vous vous demandez « pourquoi je coupe la parole ? », la question est déjà un très bon début.

Le management sans langue de bois, chaque semaine

Recherche, cas concrets et outils pour des réunions où chacun peut finir sa phrase.

Comment gérer les interruptions en réunion : 7 leviers pour les managers

L’article MIT Sloan insiste sur un point : ce n’est pas l’interruption qui fait la culture, c’est la manière dont le leadership la traite. Bonne nouvelle, cela se travaille. Voici sept leviers que nous utilisons avec les équipes que nous accompagnons.

1. Observer avant de juger

Pendant trois réunions, notez discrètement qui interrompt qui, et ce qui se passe ensuite. En visioconférence, regardez aussi le temps de parole affiché par l’outil. La plupart des managers découvrent des écarts qu’ils n’avaient jamais soupçonnés, y compris dans leur propre comportement.

2. Poser un cadre clair, ensemble

Proposez à l’équipe un accord de fonctionnement simple : « on laisse chacun finir sa phrase ». Un accord co-construit est beaucoup plus efficace qu’un rappel à l’ordre, parce qu’il donne à chacun la légitimité de le faire respecter.

3. Réparer en direct

C’est le levier le plus puissant et le plus rare. Quand quelqu’un se fait couper, le manager rend la parole immédiatement : « Attends, je voudrais entendre Sarah finir. » Une phrase, trois secondes, et toute l’équipe comprend que cette voix compte. Ne rien dire, c’est valider le verdict.

4. Parler en dernier

Si le manager donne son avis en premier, les interruptions suivantes vont toutes dans le même sens. En gardant votre position pour la fin, vous laissez les autres aller au bout de leur raisonnement sans chercher à deviner ce que vous voulez entendre.

5. Rendre l’idée à son auteur

Les chercheurs ont codé la « reprise des idées » : qui voit son idée reprise, et sous quel nom. Combien de fois une proposition ignorée devient-elle brillante dix minutes plus tard dans la bouche d’un autre ? Attribuez explicitement : « C’est ce que proposait Karim tout à l’heure, Karim, tu peux développer ? »

6. Structurer les tours de parole

Tour de table en commençant par les plus juniors, quelques minutes d’écriture individuelle avant le débat, main levée en visio : ces techniques de facilitation simples réduisent mécaniquement les interruptions de domination sans brider la spontanéité.

7. Faire tourner l’animation

Confier la facilitation à un membre différent à chaque réunion change le regard de chacun sur la dynamique de groupe. Celui qui a dû gérer les tours de parole une fois coupe beaucoup moins les autres ensuite.

Ces leviers n’ont de sens que dans un climat de sécurité psychologique : si signaler une interruption expose à des représailles, personne ne le fera.

Comment réagir quand on se fait couper la parole ?

Se faire couper la parole une fois n’a rien de dramatique. Se faire couper la parole à chaque réunion, en revanche, finit par user. Toutes les équipes n’ont pas encore un manager qui répare en direct. En attendant, voici comment reprendre la parole sans agressivité et sans vous excuser d’exister.

• Garder le fil, calmement : « Je termine mon idée et je te laisse la parole juste après. » Pas besoin de hausser le ton ni de répondre sèchement, la fermeté vient de la formulation.

• Nommer sans accuser : « Je n’avais pas fini, il me manque un point important. » Vous recentrez sur le contenu, pas sur la personne.

• Reprendre la main plus tard : si le moment est passé, « Je voudrais revenir sur ce que j’expliquais tout à l’heure » fonctionne très bien.

• Préparer avant une réunion : annoncez votre sujet à l’animateur, structurez votre prise de parole en trois points et donnez la conclusion d’abord. Il est plus difficile d’interrompre quelqu’un qui a déjà dit l’essentiel.

• En parler en tête-à-tête : si c’est un schéma récurrent, un échange privé (« j’ai remarqué que… ») évite le malentendu et laisse à l’autre une porte de sortie.

Et si c’est vous qui coupez la parole ?

La plupart des personnes qui interrompent souvent le font sans le vouloir. Pour arrêter, l’effort de volonté seul fonctionne mal. Quelques pratiques concrètes marchent mieux :

• Noter l’idée au lieu de la dire tout de suite : vous ne la perdez pas, et vous la présenterez souvent mieux.

• Pratiquer l’écoute active : reformuler ce que l’autre vient de dire avant de répondre. Impossible de reformuler une phrase qu’on n’a pas laissée finir.

• S’accorder deux secondes de silence après la fin d’une phrase. C’est inconfortable au début, puis cela devient comme un muscle.

• Demander du feedback à un collègue de confiance : « Fais-moi un signe quand je coupe quelqu’un. »

• Réparer soi-même : « Pardon, je t’ai coupé, vas-y. » C’est la marque d’un leadership solide, pas une faiblesse.

Moins d’interruptions, c’est aussi moins de ruptures d’attention pour tout le monde, et plus de chances d’atteindre ce fameux état de flow collectif où les idées s’enchaînent vraiment.

Les interruptions en trois phrases

Couper la parole n’est pas un détail : c’est l’un des moments où l’équipe lit la culture réelle, bien plus que dans les valeurs affichées.

L’interruption n’est pas toujours négative : tout dépend de qui interrompt, qui se fait couper, et de ce qui se passe ensuite.

Le leadership fait la différence : rendre la parole, attribuer les idées et structurer les échanges transforme une réunion de rapport de force en réunion d’intelligence collective.

FAQ : couper la parole en réunion

Pas toujours. Une interruption coopérative, pour compléter ou montrer son accord, peut traduire de l’énergie et de la collaboration. Elle devient un manque de respect quand elle sert à changer de sujet, à contredire sans écouter ou quand elle vise toujours les mêmes personnes.Les causes varient : position hiérarchique, enthousiasme, peur d’oublier son idée, impulsivité (parfois liée à un TDAH) ou culture d’entreprise qui récompense le plus rapide. Il vaut mieux comprendre la cause avant de réagir, car la réponse n’est pas la même.Gardez le fil calmement avec une formulation ferme et neutre, par exemple : « Je termine mon idée et je te laisse la parole juste après. » Si le schéma se répète, parlez-en en tête-à-tête avec la personne ou avec l’animateur de la réunion.En psychologie sociale, l’interruption est étudiée comme un marqueur de statut et de pouvoir dans un groupe. Les recherches récentes, comme celle publiée par MIT Sloan Management Review en 2026, la considèrent comme un indicateur culturel : elle montre quelles voix font autorité et lesquelles doivent se battre pour être entendues.Posez un accord d’équipe (on laisse finir les phrases), structurez les tours de parole, faites parler le manager en dernier, attribuez les idées à leurs auteurs et réparez immédiatement quand quelqu’un se fait couper.Utilisez la fonction main levée, désignez un animateur qui gère les tours de parole, consultez le temps de parole de chacun et prévoyez un tour de table explicite pour les décisions importantes.

Des réunions où chacun finit sa phrase

Reçois chaque semaine nos analyses sur le management, le leadership et la transformation, sans jargon ni bullshit.

SIRH : pourquoi votre empilement d’outils RH sabote votre stratégie talents (et comment reprendre la main)

Un outil pour la paie, un pour le recrutement, un pour les entretiens annuels, un pour la formation, un autre pour les congés. Chacun a été acheté pour régler un vrai problème. Ensemble, ils décident à votre place de ce qu’est un talent, de ce qu’on mesure et de ce qu’on ignore. Voici comment remettre la stratégie avant le logiciel.

Demandez à un comité de direction combien d’outils RH tourne dans l’entreprise. La réponse est presque toujours fausse, et presque toujours trop basse. Le SIRH (système d’information des ressources humaines) devait être la colonne vertébrale de la fonction RH : une source unique de vérité sur les collaborateurs, des tableaux de bord pour décider vite, des processus RH harmonisés partout. Dans la réalité, beaucoup d’organisations se retrouvent avec une constellation de solutions qui se parlent mal, configurées avec les réglages par défaut de chaque éditeur.

Sharna Wiblen et Alexis Fink, chercheuses au Center for Effective Organizations de l’Université de Californie du Sud (USC Marshall), viennent de publier dans la MIT Sloan Management Review une analyse qui met le doigt là où ça fait mal (lire l’article original, en anglais). Leur thèse : sans personnalisation réfléchie et sans architecture intentionnelle, chaque outil RH ajouté dilue un peu plus la progression stratégique de la fonction. Autrement dit, votre SIRH ne se contente pas de servir votre stratégie. Il peut la remplacer. Voici ce que ça veut dire concrètement, sans bullshit.

Qu’est-ce qu’un SIRH, et que vous a-t-on promis ?

Un SIRH est un ensemble de logiciels qui permet de gérer, d’automatiser et de centraliser les données et les processus RH tout au long du cycle de vie du collaborateur : recrutement, intégration, gestion administrative, paie, gestion des temps et des congés, évaluation, gestion des carrières, développement des compétences, rémunération. On parle parfois de logiciel SIRH au singulier, mais dans la plupart des entreprises, il s’agit d’un écosystème de modules et d’applications.

Les promesses sont toujours les mêmes, et elles sont séduisantes :

• Une source unique de vérité : des données à jour et accessibles sur les effectifs, les compétences, la masse salariale.

• De la visibilité : des tableaux de bord et des rapports qui donnent un accès instantané aux capacités et aux résultats de vos équipes.

• Des bonnes pratiques embarquées : des référentiels et des workflows standardisés à travers les unités, les fonctions et les pays.

La logique est imparable sur le papier : quand les décisions sur les talents s’appuient sur des processus structurés, des données partagées et de l’analytique intégrée, les dirigeants passent de jugements fragmentés à des décisions intentionnelles et éclairées. Le problème, c’est que la promesse est rarement tenue. Selon le rapport 2025 de la SHRM sur l’état du monde du travail cité par les autrices, moins de la moitié des professionnels RH comme des salariés jugent efficace la technologie RH de leur entreprise. Moins de la moitié. Pour des outils censés rendre la gestion des ressources humaines plus intelligente.

Le piège de l’accumulation : 80 outils RH et pas une seule stratégie

Le marché donne le vertige. Lors de la HR Technology Conference d’octobre 2025, plus de 400 éditeurs présentaient leurs solutions, dont une vague d’offres dopées à l’IA. Et cette prolifération se reproduit à l’intérieur des entreprises. Les deux chercheuses racontent avoir accompagné des organisations qui faisaient tourner de 80 à plusieurs centaines de systèmes différents.

Ce qui surprend le plus les décideurs, c’est que le problème n’est pas le manque de technologie. C’est l’excès. À l’époque des grands ERP, on avait un monolithe rigide mais cohérent. Aujourd’hui, on a un portefeuille de solutions spécialisées qui grossit sans cesse.

Peu de piles technologiques RH naissent d’un design d’architecture intentionnel. Elles grossissent par ajouts successifs de solutions ponctuelles, chacune achetée pour régler un problème local ou immédiat.D’après Sharna Wiblen et Alexis Fink, MIT Sloan Management Review (traduction libre)

Vous reconnaissez le scénario. Le recrutement se plaint de son ATS, on en achète un nouveau. Les managers trouvent l’entretien annuel pénible, on ajoute une application de feedback continu. La direction veut des indicateurs d’engagement, on branche un outil de sondage. Chaque décision est rationnelle. Le résultat global ne l’est pas : des données éclatées, des doubles saisies, des collaborateurs qui jonglent entre cinq interfaces pour poser un congé, et une direction des ressources humaines qui passe plus de temps à réconcilier des fichiers qu’à piloter les talents.

C’est exactement le même mécanisme que celui de la bureaucratie en entreprise : chaque règle ajoutée a une bonne raison, et c’est l’empilement qui tue. Et pour les équipes, cette surcharge d’interfaces nourrit directement le technostress au travail.

Fit for sale contre fit for purpose : votre logiciel SIRH pense comme son éditeur

Voici le passage le plus dérangeant de l’analyse. Vos intérêts ne sont pas ceux de vos éditeurs. Un éditeur de logiciel RH optimise pour la scalabilité et la répétabilité : il doit vendre le même produit à des centaines de clients. Les autrices le résument d’une formule : les plateformes commerciales sont conçues pour être vendables (fit for sale), alors que votre stratégie exige des systèmes adaptés à votre intention (fit for purpose).

Concrètement, les critères d’évaluation, les workflows et les capacités de reporting intégrés dans un SIRH du marché sont pensés pour fonctionner chez beaucoup de clients. Y compris chez vos concurrents. Si vous gardez les réglages par défaut, vous évaluez vos talents avec la même grille que l’entreprise d’en face. Vous définissez un « haut potentiel » comme elle. Vous mesurez la performance comme elle. Et vous vous étonnez ensuite de ne pas vous différencier sur le marché du travail.

🧭 Le point de vue Corporate Mavericks

Un outil n’est jamais neutre. Chaque champ obligatoire, chaque échelle de notation, chaque étape de validation encode une vision du management. Quand vous laissez un logiciel décider à quoi ressemble un bon entretien, un bon parcours ou une bonne augmentation, vous avez délégué votre philosophie managériale à une équipe produit qui ne connaît ni votre culture ni vos clients. Le SIRH devrait être la traduction de votre stratégie talents, pas son substitut.

5 signes que votre SIRH pilote à votre place

1. Personne ne sait dire combien d’outils RH existent. Ni la DRH, ni la direction des systèmes d’information n’a une cartographie à jour. C’est le premier symptôme du piège de l’accumulation.

2. Vos critères d’évaluation viennent du paramétrage par défaut. Si votre grille de compétences ressemble trait pour trait à la démo de l’éditeur, vous ne l’avez pas choisie, vous l’avez subie.

3. Les tableaux de bord mesurent ce qui est facile, pas ce qui compte. Taux de complétion des entretiens, nombre de formations suivies : des indicateurs d’activité, rarement des indicateurs de stratégie.

4. Chaque manager a son fichier Excel « à côté ». Quand les managers reconstruisent leurs propres outils, c’est que le système officiel ne répond pas à leurs vraies questions.

5. On adapte le processus au logiciel, jamais l’inverse. La phrase « le système ne permet pas de faire ça » est devenue un argument de décision. C’est le moment exact où l’outil a pris le pouvoir.

Tu en as marre des outils qui décident à la place des humains ?

Chaque semaine, on décortique les pratiques de management qui marchent vraiment.

Reprendre la main : un check-up « stratégie d’abord » en 4 questions

Wiblen et Fink proposent une démarche structurée en quatre étapes, la « Strategy-First Check-In », pour évaluer dans quelle mesure votre pile technologique RH et les décisions qui y sont associées servent réellement vos priorités. Le détail de leur méthode est réservé aux abonnés de la MIT SMR. Nous vous proposons ici notre propre grille, inspirée de cet esprit et de ce qu’on observe sur le terrain, à dérouler en une demi-journée avec la DRH, deux ou trois managers et un responsable SIRH.

1. Qu’est-ce qui rend notre stratégie talents unique ?

Avant de regarder le moindre logiciel, écrivez en trois phrases ce qui distingue votre manière de recruter, de développer et de fidéliser. Si vous n’y arrivez pas, aucun outil ne pourra le faire pour vous. C’est le point de départ de toute gestion des talents digne de ce nom.

2. Où ces choix sont-ils encodés dans nos outils ?

Prenez trois décisions clés (une promotion, une augmentation, un recrutement) et suivez-les dans le système. Quels champs, quels critères, quelles échelles les orientent ? Qui les a définis : vous, ou le paramétrage par défaut lors de la mise en production ?

3. Quels outils font doublon ou ne servent personne ?

Faites l’inventaire complet, y compris les applications achetées par une équipe sur sa carte de crédit. Pour chaque outil : qui l’utilise vraiment, quelle décision il éclaire, quelles données il duplique. Vous trouverez presque toujours des modules payés et inutilisés, et des données personnelles stockées en trois exemplaires (bonjour la protection des données).

4. Quelle est la règle pour ajouter (ou retirer) un outil ?

Instaurez une règle simple : aucun nouvel outil RH sans réponse écrite à deux questions. Quelle priorité stratégique sert-il ? Quel outil existant remplace-t-il ? Le principe « un entrant, un sortant » est brutal, mais c’est le seul garde-fou efficace contre l’accumulation.

Choisir son SIRH sans se faire piloter par l’éditeur

Que vous lanciez un projet SIRH ou que vous reconfiguriez l’existant, quelques principes évitent les pièges les plus fréquents :

• Partez des décisions, pas des fonctionnalités. Une démo commerciale vous montre la fonctionnalité la plus spectaculaire. Posez la question inverse : quelles décisions RH voulons-nous mieux prendre, et de quelles données avons-nous besoin pour cela ?

• Séparez le socle du différenciant. La paie, la gestion administrative, la gestion des congés et des temps, les contrats de travail : là, standardisez sans complexe et automatisez les tâches administratives au maximum. Personne ne gagne une guerre des talents grâce à son bulletin de paie original. En revanche, vos critères d’évaluation, vos parcours de carrière et votre politique de rémunération sont stratégiques : c’est là que la personnalisation doit porter.

• Impliquez les managers dès le début. Ce sont eux qui utilisent le système au quotidien. Un logiciel conçu pour la DRH et imposé aux managers finit toujours contourné.

• Méfiez-vous du « tout-en-un » comme du « best of breed ». La suite intégrée promet la cohérence mais impose sa logique. La collection d’outils spécialisés promet la souplesse mais fabrique l’accumulation. La bonne réponse dépend de votre capacité à gouverner l’architecture dans la durée.

• Donnez un propriétaire à l’architecture. Un responsable SIRH ou un chef de projet SIRH doit avoir mandat pour dire non. Un consultant SIRH externe peut aider à cartographier et à arbitrer, mais la vision doit rester interne.

Et l’IA dans les outils RH, elle arrange les choses ?

Pas automatiquement. La vague d’IA générative dans les solutions RH (tri de CV, recommandations de formation, synthèse d’entretiens, chatbots pour les collaborateurs) amplifie le problème décrit par les chercheuses. Un algorithme entraîné sur les données de centaines de clients applique une définition moyenne du bon candidat ou du bon parcours. Si vous l’activez sans le questionner, vous industrialisez des critères que vous n’avez jamais choisis.

L’IA peut être un formidable levier pour automatiser et optimiser les tâches répétitives et libérer du temps pour l’humain. Mais elle rend la question stratégique encore plus urgente : qui décide de ce qui compte ? Nous avons déjà montré comment l’IA peut faire désapprendre le jugement aux managers. Dans les RH, l’enjeu est le même, avec en prime des décisions qui touchent directement la carrière des gens.

FAQ : vos questions sur le SIRH et la stratégie RH

Un logiciel SIRH (système d’information des ressources humaines) regroupe les outils qui permettent de centraliser les données des collaborateurs et d’automatiser les processus RH : paie, gestion des temps et des congés, recrutement, entretiens, formation, gestion des compétences et des carrières. Il peut s’agir d’une suite intégrée ou d’un ensemble de modules interconnectés.On distingue généralement : la gestion administrative du personnel (contrats, paie, absences), la gestion des talents (recrutement, mobilité, carrières), le développement des compétences (formation, évaluation) et les relations sociales, avec la qualité de vie au travail. Un bon SIRH doit soutenir les quatre sans imposer sa propre vision de chacune.Le responsable SIRH pilote l’architecture des outils RH : choix des solutions, paramétrage, intégration avec les autres systèmes d’information, qualité des données, mises à jour et accompagnement des utilisateurs. Idéalement, il est aussi le garant de la cohérence entre les outils et la stratégie RH, avec le pouvoir de refuser un outil de plus.Il n’y a pas de réponse universelle. Une suite unique offre cohérence et données centralisées, mais impose sa logique. Plusieurs outils spécialisés apportent de la souplesse, mais mènent souvent au piège de l’accumulation. Le vrai critère : votre capacité à gouverner l’ensemble et à relier chaque outil à une priorité stratégique.Prenez trois décisions RH importantes et retracez-les dans vos outils. Si les critères qui les orientent viennent du paramétrage par défaut de l’éditeur, si les managers tiennent des fichiers parallèles ou si l’on adapte les processus au logiciel, votre SIRH pilote à votre place. Un check-up « stratégie d’abord » en quatre questions permet de reprendre la main.RH signifie ressources humaines. Le terme désigne à la fois la fonction de l’entreprise chargée de la gestion des ressources humaines (recrutement, paie, formation, carrières) et le service ou la direction qui l’incarne.

Le bon SIRH est celui qui sait dire votre stratégie

La technologie RH n’est plus un sujet périphérique. Elle touche chaque étape de la vie des collaborateurs et capte des données qui orientent des décisions majeures. C’est précisément pour cela qu’on ne peut plus la laisser grossir au fil des achats ponctuels et des réglages par défaut. Le message de Wiblen et Fink est simple : façonnez vos outils pour qu’ils servent vos priorités, ou ils façonneront vos priorités à votre place.

Commencez petit : un inventaire, trois décisions retracées, une règle d’entrée et de sortie des outils. Si vous voulez un regard extérieur sur votre organisation et sur la manière dont vos outils façonnent votre management, réservez un appel stratégique avec Corporate Mavericks.

La stratégie d’abord, les outils ensuite

Reçois chaque semaine nos analyses sur le management, le leadership et la transformation, sans jargon ni bullshit.

Bureaucratie en entreprise : pourquoi chaque règle ajoutée vous rend plus lent (et comment Haier en est sorti)

Une validation de plus, un comité de plus, un formulaire de plus. Chaque règle arrive avec une bonne raison. Ensemble, elles fabriquent une entreprise qui décide trop tard, loin de ses clients. Voici pourquoi la bureaucratie gagne toujours du terrain quand on grandit, et ce qu’on peut faire dès lundi pour inverser la boucle.

Personne ne se lève le matin en se disant : « Aujourd’hui, je vais ajouter de la bureaucratie en entreprise. » Et pourtant, elle progresse partout. Une étape de validation pour sécuriser un budget. Un reporting de plus pour rassurer la direction. Un comité transverse pour « aligner » les équipes. Prise isolément, chaque décision est rationnelle. Additionnées, elles produisent la même chose dans toutes les grandes structures : des décisions qui remontent pour obtenir une permission, redescendent sous forme de consignes, et arrivent sur le terrain quand le client est déjà parti.

Joost Minnaar, cofondateur de Corporate Rebels, a consacré un article à ce mal que Zhang Ruimin, fondateur du groupe Haier, appelle la « maladie de la grande entreprise » (lire l’article original, en anglais). Le sujet revient fort en ce moment : beaucoup d’entreprises suppriment des couches de management en espérant gagner en vitesse, et découvrent que retirer des chefs ne suffit pas à retirer la lourdeur. Voici ce que les sociologues, les pionniers et le terrain nous apprennent, sans bullshit.

Qu’est-ce que la bureaucratie en entreprise ?

Dans son sens courant (et souvent péjoratif), la bureaucratie désigne l’accumulation de règles, de procédures, d’étapes d’approbation et de niveaux hiérarchiques qu’une entreprise empile à mesure qu’elle grandit. Chaque couche arrive pour une raison légitime : garantir la cohérence, contrôler les risques, coordonner des équipes de plus en plus nombreuses. Le problème, c’est l’effet cumulé. Les responsabilités se diluent entre tant de bureaux que plus personne ne possède le résultat, et les personnes les plus proches du client sont celles qui ont le moins de latitude pour agir.

Quel est le synonyme de bureaucratie ? Selon le contexte, on parle de lourdeur administrative, de paperasserie, de formalisme ou de « process » pour désigner le symptôme. Le bureaucrate, lui, est historiquement l’agent d’un bureau, un employé de l’administration ou un fonctionnaire. En entreprise, le mot a glissé : il désigne quiconque fait passer le respect de la procédure avant le service rendu.

Max Weber : la bureaucratie était d’abord une promesse d’efficacité

Avant d’être une insulte, la bureaucratie a été une innovation. Le sociologue et économiste allemand Max Weber la décrivait au début du XXe siècle comme la forme la plus rationnelle d’organisation du travail collectif. Son modèle idéal repose sur quelques principes simples :

• des règles écrites et impersonnelles, identiques pour tous ;

• une hiérarchie claire où chaque subalterne sait à qui il rend des comptes ;

• une spécialisation des postes et un recrutement fondé sur les connaissances techniques ;

• un avancement fondé sur la compétence et l’ancienneté, pas sur la naissance ou le favoritisme.

Quels sont les types d’autorité selon Max Weber ? Il en distingue trois : l’autorité traditionnelle (on obéit parce que cela s’est toujours fait ainsi), le pouvoir charismatique (on suit une personne exceptionnelle) et l’autorité légale-rationnelle (on obéit à des règles reconnues). Le système bureaucratique est l’expression la plus pure de cette troisième forme. Dans sa typologie, c’était un progrès considérable face à l’arbitraire.

Mais Weber voyait aussi le revers. Il parlait d’une « cage d’acier » : une rationalité tellement efficace qu’elle finit par enfermer ceux qui la font tourner.

Merton et Crozier : quand la règle devient le but

Les sociologues qui ont suivi Weber ont décrit précisément comment la machine se dérègle. Robert K. Merton a montré, dès 1940, que les membres d’une organisation bureaucratique finissent par confondre le moyen et la fin : appliquer la procédure devient l’objectif, même quand elle ne sert plus personne. C’est ce qu’on appelle le déplacement des buts. Face à l’imprévu, l’employé ne cherche plus la bonne solution, il cherche la case du formulaire.

En France, Michel Crozier a poussé l’analyse dans Le Phénomène bureaucratique (1963). Son apport central : le cercle vicieux bureaucratique. Une structure rigide produit des dysfonctionnements. Pour les corriger, la direction ajoute des règles impersonnelles et centralise davantage. Ce qui rigidifie encore la structure, et ainsi de suite. Crozier a aussi montré que le pouvoir se loge dans les zones d’incertitude, ces zones d’ombre que les règles ne couvrent pas : celui qui maîtrise une information ou une compétence rare dispose d’un levier, et les conflits internes s’organisent autour de ces territoires.

Ce regard sociologique explique pourquoi les plans de « simplification » échouent si souvent : ils retirent des règles sans toucher aux enjeux de pouvoir qui les ont fait naître.

« Avant, les employés attendaient d’avoir des nouvelles du patron. Maintenant, ils écoutent le client. »Zhang Ruimin, fondateur de Haier, cité par Joost Minnaar (Corporate Rebels), traduction Corporate Mavericks

Le syndrome de la grande entreprise : la boucle de Tateishi

Bien avant les théories du management moderne, un ingénieur japonais avait dessiné le problème. Kazuma Tateishi, fondateur d’Omron, avertissait ses équipes dès son message de Nouvel An de 1983 que son entreprise attrapait ce qu’il appelait le « big business syndrome ». Quelques années plus tard, dans The Eternal Venture Spirit (1989), il l’a représenté sous la forme de deux boucles tournant autour d’un même centre : le profit.

La boucle du déclin : la bureaucratie retarde la communication ; ces délais diluent la responsabilité ; plus personne ne se sent propriétaire du résultat ; l’efficacité baisse, la part de marché s’érode, le profit chute. Et une entreprise dont le profit chute répond presque toujours de la même façon : plus de règles, plus de couches, plus de contrôle.

La boucle de la croissance : répondre à un vrai besoin social mène à une nouvelle technologie, qui mène à de nouveaux produits, qui gagnent des parts de marché, qui financent la capacité à repérer le besoin suivant.

Le message du schéma est brutal : une entreprise ne reste jamais immobile. Elle tourne toujours dans un sens ou dans l’autre.

Combien coûte la bureaucratie ?

Relisez les étiquettes de la mauvaise boucle : bureaucratie, délais, responsabilité diluée. Elles pointent toutes vers une seule chose, la distance. Distance entre le sommet et le terrain, entre un service et le suivant, entre l’entreprise et ceux qu’elle est censée servir. Et cette distance coûte très cher.

Gary Hamel et Michele Zanini, auteurs de Humanocracy, ont tenté de la chiffrer. Selon leurs estimations reprises par Corporate Rebels, l’excès de bureaucratie coûterait environ 3 000 milliards de dollars par an à l’économie américaine, et diviser par deux le fardeau bureaucratique dans les pays de l’OCDE ajouterait quelque 9 000 milliards de dollars de production économique.

La bureaucratie est-elle forcément mauvaise ? Non. Un peu de structure, au bon endroit, est utile : la paie doit être prévisible, la sécurité ne se négocie pas. Le problème commence quand écrire des règles devient la principale production de l’entreprise. C’est exactement ce que la boucle de Tateishi décrit.

Ton entreprise tourne dans la mauvaise boucle ?

Chaque semaine, des cas concrets d’entreprises qui ont cassé la bureaucratie (et ce que tu peux en tirer), sans jargon.

Zéro distance : comment Haier a soigné sa maladie bureaucratique

Zhang Ruimin a reconnu chez Haier le même mal que Tateishi. Son objectif n’était pas de corriger quelques inefficacités, mais de sortir de la mauvaise boucle pour de bon. Sa réponse porte un nom : Zero Distance. Elle repose sur deux mouvements.

• Zéro distance : supprimer les barrières physiques, informationnelles et émotionnelles entre l’entreprise et ses utilisateurs. Passer d’une logique d’offre à une logique de demande, et laisser les besoins des clients, pas la politique interne, fixer l’agenda.

• Zéro frontière : dissoudre les murs entre équipes, entre fonctions, et même avec les fournisseurs, les partenaires et parfois les concurrents. Construire un réseau ouvert plutôt qu’une forteresse.

Concrètement, Haier a démonté sa hiérarchie en une vingtaine d’années pour devenir un réseau de micro-entreprises, le modèle RenDanHeYi. En 2012, l’entreprise a donné à 12 000 managers un choix : partir, ou rejoindre la nouvelle structure. Certains sont partis. Beaucoup sont restés et ont intégré l’une des quelque 4 000 petites entreprises internes.

Ce qu’est une micro-entreprise chez Haier

• Une équipe d’environ quinze personnes qui fonctionne comme une startup.

• Elle possède son propre compte de résultat, choisit ses leaders et fixe sa stratégie.

• Elle est évaluée sur la valeur créée pour les utilisateurs, pas sur sa loyauté envers un chef.

• Les équipes contractent entre elles via des marchés internes : ce ne sont plus les managers qui distribuent le travail.

• Ce sont les clients qui financent les salaires. Pas d’utilisateurs, pas de financement.

L’exemple le plus parlant cité par Joost Minnaar est Thunderobot : un jeune salarié de Haier repère la demande croissante pour les ordinateurs portables de gaming, la poursuit sous forme de micro-entreprise, et Thunderobot finit par entrer en Bourse. Environ la moitié des nouvelles micro-entreprises de Haier réussissent, quand seulement 10 % environ des startups indépendantes survivent. Donner aux gens la propriété du résultat, les droits de décision et un salaire payé par le client change l’équation.

Attention au contresens : RenDanHeYi n’est pas un modèle à télécharger. C’est le fruit de deux décennies d’expérimentations, d’erreurs et de décisions radicales. Copier la forme sans le chemin, c’est le meilleur moyen de rater, comme nous l’avions expliqué à propos de l’holacratie copiée-collée.

Les 5 signes que votre entreprise tourne dans la mauvaise boucle

Le diagnostic de Tateishi est universel : la boucle du déclin démarre dès que l’entreprise commence à grandir. Elle n’attend pas que vous soyez prêts. Elle s’installe par une validation en plus, une couche en plus, un « on monte un groupe de travail ». Quelques signaux qui ne trompent pas :

1. Les décisions ralentissent alors que le marché, lui, accélère. Une décision simple met des semaines à être prise (voir notre article pour accélérer la prise de décision).

2. Le terrain ne sait plus expliquer ce que fait la direction, et inversement.

3. Les besoins clients arrivent filtrés par des présentations et des intermédiaires.

4. Chaque incident produit une nouvelle règle, jamais une règle supprimée.

5. Les services défendent leur territoire plutôt que le résultat commun : les silos organisationnels deviennent la norme.

Si vous cochez trois cases sur cinq, la question n’est plus de savoir si votre entreprise a de la bureaucratie. Elle en a. La question est de savoir dans quelle boucle elle tourne aujourd’hui.

Le piège de la simplification par le haut

Beaucoup de directions répondent à la lourdeur par un grand programme de simplification. Avec un comité de pilotage, un reporting d’avancement et une validation des quick wins. Vous voyez le problème.

Supprimer des étages de management sans redonner de pouvoir de décision au terrain ne fait que déplacer le goulot : la charge remonte vers les rares managers restants, et la chaîne de commandement devient un point de défaillance unique. Le remède n’est pas d’avoir moins de chefs. C’est de réduire la distance.

Comment réduire la bureaucratie en entreprise sans tout casser ?

Personne ne vous demande de découper votre société en 4 000 morceaux lundi matin. Comme le rappelle Joost Minnaar, on peut commencer petit. Voici des actions concrètes, testées chez nos clients, pour remettre l’entreprise dans la bonne boucle :

1. Descendez une décision

Choisissez une décision qui remonte aujourd’hui systématiquement (une dépense, un geste commercial, un recrutement) et confiez-la à l’équipe qui vit le problème, avec un cadre clair : un budget, une limite, une obligation de partager le résultat.

2. Supprimez un comité

Listez les instances récurrentes et demandez pour chacune : quelle décision a-t-elle prise ces trois derniers mois ? Si la réponse est « aucune », supprimez-la pendant un trimestre et observez ce qui manque vraiment.

3. Donnez un résultat client de bout en bout à une équipe

Plutôt que de répartir un parcours client entre cinq services, confiez-le à une seule équipe pluridisciplinaire capable de coordonner tout le flux. Elle saura qui appeler quand ça casse : elle-même.

4. Appliquez la règle « une entrée, une sortie »

Chaque nouvelle procédure doit en remplacer une ancienne. C’est la façon la plus simple de casser le cercle vicieux décrit par Crozier, où chaque problème produit une règle sans que jamais aucune ne disparaisse.

5. Rapprochez physiquement les équipes du client

Faites assister les managers et les fonctions support à des appels clients, à des sessions de support, à des visites terrain. La meilleure arme contre l’organisation bureaucratique reste le contact direct avec ceux qui paient.

À retenir : la bureaucratie n’est pas un défaut moral des bureaucrates. C’est une pente naturelle des structures qui grandissent. On ne la combat pas avec plus de contrôle, on la combat en réduisant la distance entre ceux qui décident, ceux qui font et ceux qui achètent. Pour aller plus loin sur ce que l’autonomie exige vraiment, lisez notre article sur l’autogestion en entreprise.

FAQ : la bureaucratie en entreprise

C’est une organisation fondée sur des règles écrites et impersonnelles, une hiérarchie formelle, la spécialisation des postes et des procédures standardisées. Max Weber y voyait la forme la plus rationnelle d’autorité. Ses dérives apparaissent quand la règle devient une fin en soi.À l’origine, un bureaucrate est un agent d’un bureau ou de l’administration, souvent un fonctionnaire. Dans le langage courant, le terme est devenu péjoratif : il désigne une personne qui privilégie l’application formelle des procédures au détriment du service rendu ou du bon sens.Weber distingue trois types d’autorité légitime : l’autorité traditionnelle, fondée sur la coutume ; l’autorité charismatique, fondée sur les qualités exceptionnelles d’un chef ; et l’autorité légale-rationnelle, fondée sur des règles reconnues, dont la bureaucratie est la forme la plus aboutie.Selon le contexte : lourdeur administrative, paperasserie, formalisme, administration ou, en entreprise, excès de process. Le mot désigne à la fois une forme d’organisation (au sens de Weber) et ses excès.Rapprochez les décisions du terrain, supprimez les comités qui ne décident rien, confiez des résultats clients de bout en bout à des équipes autonomes et imposez qu’une nouvelle règle en remplace une ancienne. L’objectif est de réduire la distance, pas seulement le nombre de managers.Non. Un minimum de structure est utile pour la paie, la sécurité ou la conformité légale. Elle devient coûteuse quand elle ralentit les décisions, dilue la responsabilité et coupe l’entreprise de ses clients.

Dans quel sens tourne votre entreprise aujourd’hui ?

Tateishi l’avait dessiné il y a plus de quarante ans : une entreprise n’est jamais à l’arrêt. Chaque règle ajoutée, chaque validation supplémentaire, chaque comité créé la pousse un peu plus dans la boucle du déclin. Chaque décision rendue au terrain, chaque contact direct avec le client, chaque équipe qui possède son résultat la ramène vers la boucle de la croissance.

La bonne nouvelle, c’est que le remède n’a rien d’exotique. Il commence par une décision descendue, un comité supprimé, une équipe responsabilisée. Si vous voulez identifier où se loge la distance dans votre structure et par où commencer, réservez un appel stratégique avec Corporate Mavericks.

Moins de règles, plus de résultats

Reçois chaque semaine nos analyses sur le management, le leadership et la transformation, sans jargon ni bullshit.