L'ego en développement logiciel : le biais que personne ne veut voir

•
mindset culture ego

L’égo, on en a tous. Mais peu de personnes voient les dégâts qu’il laisse derrière lui.

L’Agile, TDD, le Craft, les microservices et maintenant l’IA… : à chaque vague, le même schéma. On découvre un concept. On l’adopte. On en fait une identité. Puis on juge ceux qui font autrement.

L’égo est visible partout depuis toujours.

Ce n’est pas un défaut de caractère. C’est un réflexe systémique. Et il agit avant même qu’on s’en rende compte.

Les biais invisibles qui protègent notre égo

On aime penser qu’on est rationnel. Que nos choix techniques sont objectifs. Que nos opinions sont fondées sur des faits.

La recherche dit le contraire. Une étude publiée dans Communications of the ACM (une revue scientifique de référence en informatique) a identifié 37 biais cognitifs spécifiques à l’ingénierie logicielle.

Parmi eux, cinq nourrissent directement l’égo.

L’effet IKEA. On surestime la valeur de ce qu’on a construit soi-même. Ton environnement de travail avec l’IA que tu as passé trois semaines à configurer ? Tu le trouves meilleur que celui du voisin. Pas parce qu’il l’est, mais parce que c’est le tien. Ton architecture ? Pareil. Ta façon d’écrire des tests ? Pareil.

Le biais de confirmation. On lit pour valider ce qu’on pense déjà. Quelqu’un partage un post sur une approche différente de la tienne. Au lieu de tester, tu cherches la faille. Tu lis pour confirmer, pas pour apprendre.

Le piège de l’investissement passé. « J’ai investi trois semaines à configurer cette stack, elle DOIT être la bonne approche. » L’investissement passé devient un argument. Pas la pertinence actuelle.

La fusion identitaire. C’est le plus vicieux. Ta méthode devient ton expertise. Ton expertise devient ton identité. Critiquer ta méthode, c’est te critiquer toi. Le code devient personnel. Et la revue de code devient une attaque.

L’aversion à l’erreur. L’ego transforme l’erreur en menace identitaire. Se tromper, c’est être incompétent. Donc on évite le risque, on ne propose pas, on reste dans le connu. L’aversion à l’erreur n’est pas de la prudence. C’est l’égo qui protège son image.

Le cercle est vicieux. L’industrie le nourrit. Quand on te répète que tu es un expert incontournable, tu finis par le croire. Et gare à celui qui remet en question ton expertise.

L’égo au quotidien

L’égo ne se cache pas que dans les débats sur l’IA. Il est dans les rituels de tous les jours.

Les retours sur le code. « Fait comme ci. » « Ça ne va pas. » « Change ça. » Sans explication. Les retours pilotés par l’égo ressemblent à des directives, pas à des échanges.

Les décisions d’architecture. Un responsable qui a choisi une architecture la défendra même quand les preuves montrent le contraire. Pas par incompétence, par identité. C’est « son » architecture. La remettre en question, c’est remettre en question son jugement. Et par extension, sa légitimité.

Les directives imposées. « On fait comme ça parce que c’est la bonne pratique. » Sans explication. Sans écoute du contexte. Le « pourquoi » disparaît derrière l’argument d’autorité. La bonne pratique de qui ? Dans quel contexte ? Pour quel problème ?

Le mentorat inversé. Le senior qui refait le code du junior au lieu de l’accompagner. Ce n’est pas du mentorat. C’est de l’égo déguisé en aide. Le message implicite : « tu n’es pas capable, laisse-moi faire. »

Erving Goffman a théorisé ces mécanismes en 1956 : la gestion de la « face ». C’est la valeur sociale qu’on projette et qu’on protège dans chaque interaction. Lorsqu’on questionne votre expertise, votre façon de faire, votre légitimité ; l’égo prend le relais avant même que la raison intervienne.

Paradoxalement, Elliot Aronson a démontré en 1966 l’inverse de ce qu’on croit : admettre une erreur augmente la crédibilité, pas l’inverse. L’effet Pratfall. À une condition : que la compétence soit déjà établie. Les développeurs les plus expérimentés ont donc précisément le plus à gagner à dire « tu avais raison ». Et c’est souvent eux qui le font le moins.

Tous ces comportements ont un point commun. Ils ne viennent pas d’une mauvaise intention. Ils viennent d’un réflexe. L’égo se protège avant même qu’on s’en rende compte.

Des initiatives comme les Conventional Comments tentent de cadrer le problème en revue de code. En préfixant chaque commentaire par son intention (suggestion, question, remarque mineure, problème), on force l’auteur à qualifier son retour avant de l’écrire. « Suggestion : as-tu envisagé X ? » n’a pas le même effet que « change ça ». Le cadre réduit l’espace pour l’égo.

L’IA : la dernière preuve que rien n’a changé

En février 2025, Andrej Karpathy, ancien directeur de l’IA chez Tesla, tweete le terme « vibe coding » : coder en laissant l’IA générer, sans lire le code, en suivant l’intuition. Le tweet fait 4,5 millions de vues.

Les réseaux deviennent alors un théâtre :

  • Des produits SaaS créés en quelques heures.
  • Des formations qui promettent à n’importe qui de générer des milliers d’euros par mois.
  • Des prises de position sur Cursor, Claude Code ou Copilot : les autres ont tort.

Ce ne sont pas des personnages de mauvaise foi. Ce sont les mêmes réflexes décrits plus haut, appliqués à un nouvel outil.

L’investissement crée la surestimation. La méthode devient identité. Et l’identité rend l’erreur invisible.

Il y a aussi un besoin plus profond : le sentiment d’appartenance. Choisir Cursor ou Claude Code, c’est rejoindre une tribu. Et une tribu se définit autant par ce qu’elle défend que par ce qu’elle rejette. L’égo individuel se fond dans l’égo collectif.

Mais le plus révélateur, c’est l’étude METR (un laboratoire de recherche indépendant spécialisé en évaluation des IA) publiée en 2025. Des chercheurs ont mesuré la productivité réelle de 16 développeurs expérimentés sur 246 tâches, avec et sans IA. Résultat : les développeurs assistés par IA étaient 19% plus lents. Pourtant, ils estimaient être 20% plus rapides.

Ils étaient convaincus d’être plus productifs. Ils ne l’étaient pas.

Et cela va plus loin. En 2025, une étude publiée dans Nature a mesuré que les LLMs sont en moyenne 50% plus sycophantes (enclins à approuver plutôt qu’à contredire) que les humains. OpenAI a d’ailleurs dû annuler une mise à jour de GPT-4o : le modèle validait des contenus erronés parce qu’il cherchait à plaire. Ce n’est pas un bug. C’est un comportement par défaut. Notre égo a trouvé un miroir parfait : quelqu’un qui ne dit jamais non.

Elle touche aussi à l’identité. Mo Bitar, fondateur de Standard Notes (une application de notes chiffrées), a fait une vidéo sur X avec pratiquement 6M de vues. Il se décrit comme un « 10x engineer » et se voit maintenant inutile depuis l’arrivée des assistants IA. Pas inefficace. Inutile.

L’égo technique ne protégeait pas juste une méthode. Il protégeait une rareté : la maîtrise d’une compétence que peu possédaient. Quand l’IA démocratise cette compétence en quelques prompts, ce n’est plus la revue de code qui menace l’identité. C’est l’outil lui-même.

« Egoless » : le mot que tout le monde prononce, personne ne pratique pleinement

Le concept d’« egoless programming » a été inventé en 1971. Ça fait plus de 50 ans.

Tout le monde connaît le principe. Personne ne l’applique pleinement.

Il existe aussi le principe : « Strong opinions, weakly held » (des convictions fortes, tenues légèrement). L’idée originale de Paul Saffo est saine : avoir des convictions fortes tout en étant prêt à les abandonner face aux épreuves. En pratique, on retient « strong opinions » et on oublie « weakly held ». Ça devient une permission d’être dogmatique.

Le coach agile qui impose SA méthode. Le tech lead qui « fait du mentoring » mais n’écoute jamais. Le senior qui prône l’ouverture d’esprit mais refuse de tester l’approche du junior. L’écart entre le discours et la pratique est un classique de l’ego.

Je me croyais egoless. Je ne l’étais pas.

Pendant des années, je me suis considéré comme quelqu’un d’ouvert. À l’écoute. Prêt à me remettre en question. J’en étais convaincu.

Jusqu’à une mission où un responsable a commencé à remettre en cause tous mes choix, mon approche, ma façon de faire. Et au lieu de l’écouter, je me suis senti attaqué. Défensif. En justification permanente. Malgré ma lucidité en temps réel, je n’arrivais pas à contrôler ma réaction.

J’avais déjà été remis en question avant, et ça ne posait aucun problème. Ce n’était pas une question de confrontation. C’était le contexte et l’égo de l’autre qui réactivaient le mien. Face à quelqu’un qui impose, tu te mets à défendre.

C’est l’effet miroir. L’égo des autres ne nous agresse pas réellement, il nous révèle. Certains découvrent qu’ils ont aussi besoin d’imposer. D’autres réalisent qu’ils ont besoin de prendre leur place, de revenir à un sentiment d’égalité. Quand toutes les décisions sont prises par une seule personne et que toutes les tiennes sont refusées, ce n’est plus une question d’égo individuel. C’est un climat d’inégalité. Et l’égo qui se réveille à ce moment-là n’est pas toxique. C’est une réaction saine face à un déséquilibre.

Cette expérience a été une des plus formatrices de ma carrière. Non pas parce que l’autre avait raison ou tort. Mais parce que j’ai réalisé que l’égoless n’est pas une qualité individuelle. C’est le produit d’un environnement. Dans un contexte sain, l’égo s’efface naturellement. Dans un contexte toxique, il devient un mécanisme de protection.

Et j’en ai eu la preuve inverse.

Six mois de mob programming dans une autre mission. Zéro bataille d’égo. Les échanges étaient naturellement constructifs. Chacun faisait des concessions acceptées par tous. L’alignement se faisait organiquement. Le flow de productivité ne dépendait pas d’un individu, il se poursuivait même quand quelqu’un quittait la salle.

L’égoless n’est pas un effort individuel. C’est un résultat collectif. Et il a besoin d’un cadre pour exister.

Ce que l’égo coûte aux équipes

Ron Westrum a identifié trois types de cultures organisationnelles, du plus toxique au plus sain :

  • Pathologique : l’information est cachée, les messagers sont punis, l’échec est couvert. C’est la culture de l’égo à l’échelle d’une organisation.
  • Bureaucratique : les territoires sont protégés, les règles priment sur la coopération.
  • Générative : la coopération prime, les risques sont partagés, l’échec mène à l’investigation.

La culture générative ne se décrète pas. Elle naît quand chacun peut dire « je me suis trompé » sans craindre les conséquences.

Amy Edmondson a montré que les meilleures équipes hospitalières rapportaient plus d’erreurs, pas moins. Pas parce qu’elles en faisaient plus. Parce qu’elles osaient les partager. Oser dire « je me suis trompé » sans craindre le jugement.

Google l’a confirmé avec le Project Aristotle : après avoir étudié 180 équipes pendant 2 ans, la sécurité psychologique est le facteur numéro un des équipes performantes. Pas la compétence technique. Pas les process. La capacité à se montrer vulnérable.

Et Forsgren, Humble et Kim l’ont chiffré dans Accelerate : les cultures pilotées par l’égo corrèlent directement avec une mauvaise performance de livraison.

On sait tout ça depuis des décennies mais on continue.

Conclusion

L’égo en développement logiciel n’est pas un problème de personnalité. C’est un biais systémique, nourri par nos câblages cognitifs, amplifié par une industrie qui glorifie les héros individuels, et reproduit à chaque nouvelle vague technologique.

Mais reconnaître le problème n’est que la première étape. Le deuxième article de cette série explore des cas concrets où l’égo se manifeste au quotidien : du syndrome de Dunning-Kruger au mythe du 10x developer, en passant par le perfectionnisme déguisé en exigence.

Et le troisième parle de ce qui marche vraiment pour désarmer l’égo, individuellement et collectivement. De l’écoute active au triangle de Karpman, en passant par les dynamiques de pouvoir invisibles qui le nourrissent.

L’égo ne disparaîtra pas. Et ce n’est pas le but. Le but, c’est de le déceler. Savoir quand il te protège et quand il te bloque. Quand il te donne la confiance de défendre une idée et quand il t’empêche d’écouter celle de l’autre.

La prochaine fois que tu examines le code d’un collègue, que tu rentres en réunion d’architecture, ou que tu lis un post sur une méthode différente de la tienne, pose-toi la question : c’est moi qui parle, ou c’est mon égo ?

Sources