Le syndrome « pas inventé ici »

Une idée, un composant ou une méthode est écartée non pour ses défauts, mais parce qu'elle ne vient pas de chez nous.

Biais≈ 11 min de lectureVérifié en partieLecture

FréquenceFréquentPlusieurs fois par projet.

Où le rencontre-t-on

Choix de composants
Réutilisation
Open source
Choix d'outils
Relations entre équipes
Innovation

Aide de l’IAPartielleElle aide, mais elle subit aussi le piège. Voir comment ↓

En bref

Quoi : on écarte ou on refait en interne ce qui a été conçu ailleurs, sans l'avoir évalué sur le fond.
Pourquoi : fierté du métier, identité de groupe, perte de contrôle perçue, goût de ce qu'on a construit.
Détecter : « on ferait mieux nous-mêmes », critères d'évaluation différents pour le dehors et le dedans.
Éviter : comparer construire, acheter et réutiliser sur les mêmes critères, chiffrer le coût complet, tenir un registre des décisions.

Sur cette page

Définition#

**Ralph Katz**Américaindate de naissance non publiéeChercheur en management de l'innovation, auteur avec Thomas Allen de l'étude de 1982 sur le syndrome NIH

Le syndrome « pas inventé ici » (not invented here, NIH) est la tendance d'un groupe à refuser une idée, un produit ou une pratique parce qu'ils viennent de l'extérieur, même quand ils conviendraient. Le résultat typique : on reconstruit en interne ce qui existait déjà, à plus grand coût et souvent avec moins de qualité.

L'expression est ancienne dans la gestion de la recherche et développement. Elle a été étudiée par Ralph Katz et Thomas Allen (1982), qui ont examiné 50 groupes de projet de R&D dans trois organisations : les équipes dont l'ancienneté moyenne était longue communiquaient moins avec l'extérieur de leur organisation et avaient de moins bons résultats.

Ce n'est pas un biais cognitif « pur » : il combine plusieurs mécanismes (voir ci-dessous) et un facteur organisationnel, la culture du groupe. C'est pourquoi on le range parmi les biais de décision collective.

Le mécanisme#

Identité et fierté. Pour une équipe d'ingénieurs, adopter la solution d'un autre peut sembler admettre qu'on ne savait pas la faire. Les compétences et l'autonomie font partie de l'identité du groupe.
L'effet « maison ». On connaît les défauts de ce qu'on a écrit et l'on pardonne ; on ne voit que les défauts de ce qu'on n'a pas écrit (voir l'effet IKEA et le biais d'appartenance au groupe).
Contrôle perçu. Dépendre d'un composant extérieur est vécu comme une perte de maîtrise (délais, évolutions, support). Le risque est réel, mais il est généralement surévalué par rapport au risque, plus diffus, de ce qu'on maintient soi-même.
Coûts invisibles. Le coût d'achat est affiché ; le coût de construction, de maintenance et d'opportunité ne l'est pas. La comparaison est faussée avant d'avoir commencé.
Isolement progressif. Plus un groupe est stable et fermé, moins il reçoit d'idées neuves, et plus il les juge suspectes : c'est la dynamique relevée par Katz et Allen.

Chaque rejet réduit les contacts avec l'extérieur, ce qui renforce l'impression que l'extérieur n'a rien à apporter. La parade consiste à imposer une comparaison objective avant la décision.Survolez ou touchez un élément pour en lire le détail.

Où on le rencontre#

En conduite de projet#

Choix de composants : « on va écrire notre propre moteur de workflow / notre bibliothèque d'accès aux données / notre ordonnanceur » alors qu'il en existe de matures.
Open source et fournisseurs : la bibliothèque existante est écartée sur un défaut mineur, ou sur un détail de style, alors qu'on tolère bien pire dans le code maison.
Outils d'une autre équipe : le service voisin propose son framework de tests ou son module d'authentification, et chaque équipe finit par maintenir le sien.
Réutilisation de l'existant : un composant hérité d'un autre projet est refait « parce qu'on ne comprend pas comment il marche », sans l'avoir lu.
Normes et pratiques externes : on réinvente un format d'échange, une convention de nommage ou un processus alors qu'un standard existe.

En management#

Méthodes venues d'ailleurs : une pratique d'une autre entreprise, d'un autre service ou d'un livre est rejetée d'emblée (« ça ne marcherait pas chez nous »), sans test.
Recrutement et conseil : l'avis d'un consultant ou d'un nouvel embauché est moins écouté que celui d'un collègue de longue date, à contenu égal.
Relations entre services : un service refuse les livrables d'un autre « parce que ce n'est pas notre façon de faire », et chacun construit son propre outil de suivi.
Dynamique d'équipe : les équipes qui travaillent ensemble depuis longtemps se ferment aux nouvelles idées sans s'en rendre compte.

Cas célèbres#

Étude

L'ancienneté d'un groupe et son isolement 1982#

Biais en jeu : NIH, isolement du groupe de projet.

50groupes de projet de R&D étudiés

3organisations

1982publication dans R&D Management

Ce qui s'est passé. Ralph Katz et Thomas Allen étudient la performance de 50 groupes de projet de R&D dans trois organisations. Ils constatent que, passé un certain nombre d'années de stabilité, les groupes communiquent moins avec les collègues extérieurs et avec l'information extérieure, et que leurs résultats se dégradent. Les groupes anciens deviennent « autosuffisants » aux yeux de leurs membres, ce qui est exactement le terrain du NIH.

Ce que cela illustre

Un groupe très soudé et stable est efficace dans l'exécution et vulnérable à l'enfermement. Renouveler les regards (rotations, relecteurs externes, échanges avec d'autres équipes) n'est pas un luxe de curieux, c'est une protection mesurée contre le NIH.

Cas célèbre

Procter & Gamble : de « pas inventé ici » à « fièrement trouvé ailleurs » 2000-2006#

Biais en jeu : NIH, dépendance à la R&D interne.

~10 % → plus de 50 %part des inventions de nouveaux produits issue de l'extérieur, entre 2000 et 2006

4,8 % → 3,4 %R&D rapportée au chiffre d'affaires

~60 %hausse de la productivité de la R&D

Ce qui s'est passé. Au début des années 2000, le groupe américain Procter & Gamble constate que ses coûts de R&D montent plus vite que son chiffre d'affaires et que le rythme des innovations ne suffit plus. Sous l'impulsion de son directeur général A.G. Lafley, il fixe l'objectif qu'au moins la moitié de ses innovations vienne de l'extérieur, et met en place le modèle « Connect + Develop » (réseau de chercheurs, brevets, partenaires). Dans Harvard Business Review en mars 2006, Larry Huston et Nabil Sakkab rapportent une productivité de la R&D en hausse d'environ 60 %, un taux de réussite des innovations plus que doublé et une R&D passée de 4,8 % à 3,4 % du chiffre d'affaires.

Chiffres rapportés par Huston et Sakkab (HBR, 2006), pour l'année 2000 puis pour l'année de l'article.

Ce que cela illustre

L'entreprise n'a pas cessé de faire de la recherche : elle a cessé de penser que seule la recherche maison comptait. À noter que ces chiffres sont ceux que l'entreprise a elle-même publiés ; la baisse de la R&D en proportion ne vient pas seulement du modèle ouvert. Le réflexe à retenir : ce que vous fabriquez n'est pas meilleur parce que c'est vous qui l'avez fait, et le coût d'entretenir tout en interne finit par se voir.

Contre-exemple

Le contre-exemple de left-pad 22 mars 2016#

Biais en jeu : excès inverse, dépendance non maîtrisée à un composant extérieur.

11 lignesde code pour la fonction concernée

273paquets retirés du registre par leur auteur

Ce qui s'est passé. Le 22 mars 2016, un développeur, Azer Koçulu, retire du registre npm l'ensemble de ses paquets (273) à la suite d'un différend sur un nom de paquet. L'un d'eux, left-pad, une fonction d'une dizaine de lignes qui complète une chaîne à gauche, est utilisé, directement ou non, par un très grand nombre de projets JavaScript. Les constructions de nombreux projets échouent pendant plusieurs heures, jusqu'à ce que npm restaure le paquet.

Ce que cela illustre

Se garder du NIH ne veut pas dire importer sans réfléchir. Une dépendance a un coût : disponibilité, licence, sécurité, évolution. Pour onze lignes, écrire soi-même et tester peut être le bon choix ; pour un moteur de chiffrement, jamais. La bonne attitude est de décider sur des critères, pas sur la provenance, dans un sens ou dans l'autre.

Signaux de détection#

« On ferait ça mieux nous-mêmes » dit avant toute évaluation.
Les critères appliqués au produit extérieur (maturité, support, sécurité) ne sont pas appliqués au code maison.
Plusieurs équipes de la même entreprise maintiennent des outils équivalents.
Le coût de développement interne est comparé au prix d'achat sans la maintenance sur plusieurs années.
Les arguments contre la solution extérieure sont vagues (« pas adapté à notre contexte », « on perdrait la main »).
Les idées de nouveaux arrivants ou d'équipes voisines sont reçues avec condescendance.

Réflexes d'évitement#

Appliquer les mêmes critères aux deux côtés. Rédigez la grille avant l'examen (fonctions, qualité, sécurité, licence, coût, évolutivité) et notez la solution interne et les solutions extérieures avec la même grille.
Chiffrer le coût complet. Développement, tests, documentation, maintenance, montée en compétence, astreinte : sur trois à cinq ans, pour construire comme pour acheter ou réutiliser.
Se demander ce qui nous différencie. Construire ce qui fait la valeur propre du produit ; acheter ou réutiliser ce qui est banal (authentification, journalisation, formats, ordonnancement).
Tester avant de rejeter. Une preuve de concept courte, bornée, vaut mieux qu'un jugement sur dossier.
Ouvrir le groupe. Revues croisées avec d'autres équipes, rotations, présentations externes, veille régulière : les groupes qui échangent résistent mieux au NIH.
Tracer la décision. Consignez les options, les critères et la raison du choix (un enregistrement de décision d'architecture suffit) pour pouvoir la revoir.
Valoriser le réemploi. Reconnaître publiquement ceux qui adoptent la bonne solution d'autrui plutôt que ceux qui réécrivent.

Avec l'IA : détecter, remédier, atténuer#

Aide de l'IA estimée : partielle

L'IA est utile pour élargir l'état de l'art et construire une grille de comparaison neutre. Mais elle ne connaît pas votre contexte, peut ignorer des solutions récentes, et elle invente parfois des bibliothèques ou des fonctions qui n'existent pas. Le NIH est surtout un phénomène de culture : elle l'éclaire sans le dissoudre.

Détecter#

Relever, dans un dossier de décision, les critères asymétriques entre l'option interne et les options extérieures.
Repérer les justifications sans fait (« pas adapté », « trop risqué »).
Lister des composants existants pour un besoin donné, à vérifier ensuite.

Remédier#

Construire une grille de comparaison construire / acheter / réutiliser avec critères pondérés.
Estimer le coût complet de chaque option sur plusieurs années, avec hypothèses explicites.
Rédiger une preuve de concept ou un plan d'essai borné.

Atténuer#

Jouer l'avocat de l'option extérieure pour obliger le groupe à y répondre point par point.
Synthétiser la veille externe (articles, notes de version) pour nourrir régulièrement l'équipe.
Faire reformuler le besoin sans solution, pour éviter qu'il ne désigne déjà l'outil maison.

Prompts à intégrer à vos usages#

1. Grille construire, acheter ou réutiliser. Avant de décider de développer un composant en interne.

Nous envisageons de développer en interne [composant / fonction]. Aide-moi à comparer objectivement trois options : construire, réutiliser une solution existante (open source ou commerciale), ou adapter un composant interne existant.
1. Propose une grille de 8 à 10 critères (fonctionnalités, qualité, sécurité, licence, coût d'acquisition, coût de maintenance sur 5 ans, évolutivité, support, risque de dépendance, compétences requises).
2. Pour chaque option, indique ce qu'il faudrait savoir pour la noter, sans inventer de données : signale ce que tu ne sais pas.
3. Cite des familles de solutions existantes à examiner, en précisant qu'il faudra vérifier leur existence et leur état actuel.

Contexte : [besoin, contraintes, compétences, durée de vie attendue]

2. Avocat de la solution extérieure. Quand l'équipe écarte une solution avant de l'avoir évaluée.

Voici les raisons pour lesquelles nous écartons [solution extérieure] : [liste].
Joue l'avocat de cette solution. Pour chaque raison, dis si elle repose sur un fait vérifiable ou sur une impression, quelle vérification permettrait de la tester, et si la même objection s'appliquerait à notre solution interne.
Termine par les trois essais les moins coûteux qui permettraient de trancher.

Comment les intégrer#

À l'avant-projet : le prompt 1 produit une grille que l'équipe corrige et valide avant de choisir.
En comité d'architecture : le prompt 2 sert de contradicteur sur toute décision de construire.
En rétrospective : revoir les décisions de construire d'il y a un an, avec leur coût réel.

Précautions#

Vérifiez que les produits, bibliothèques et versions cités existent : une IA peut en inventer ou citer des projets abandonnés.
Ne collez pas de code propriétaire, de contrats ni de données client dans un outil non autorisé.
Une grille produite par l'IA reflète le vocabulaire courant ; les critères propres à votre contexte (réglementation, hébergement, souveraineté) sont à ajouter vous-même.

Limites#

Le NIH est un syndrome organisationnel plus qu'un biais individuel mesurable ; les études sont surtout des enquêtes de terrain, dont les résultats dépendent du contexte.
Refuser une solution extérieure n'est pas toujours du NIH : la sécurité, la licence, la souveraineté, le coût de migration ou l'avantage concurrentiel peuvent être de bonnes raisons. Le biais commence quand la raison est la provenance.
L'excès inverse existe : dépendre de tout, c'est aussi perdre le contrôle (voir le cas de left-pad), et un goût systématique pour l'extérieur relève du biais pro-innovation ou de l'effet de mode.
Les chiffres de Procter & Gamble viennent de la communication de l'entreprise elle-même.

Sources et vérification#

Katz & Allen (1982), « Investigating the Not Invented Here (NIH) syndrome: A look at the performance, tenure, and communication patterns of 50 R&D Project Groups », R&D Management, 12(1)
Huston & Sakkab (2006), « Connect and Develop: Inside Procter & Gamble's New Model for Innovation », Harvard Business Review, mars 2006
Quartz (2016), « How one programmer broke the internet by deleting a tiny piece of code » — l'affaire left-pad.
Lafley, A. G. & Charan, R. (2008), The Game-Changer, Crown Business — la démarche d'innovation ouverte chez Procter & Gamble.

Voir aussi#

Se combine avec, ou renforce#

Ces biais se nourrissent l’un l’autre.

Biais voisins#

Des variantes ou des cousins : à ne pas confondre.

Contrepoids et réflexes associés#

Ce qui le neutralise.

Le biais pro-innovation
L'analyse construire ou acheter (build or buy) (notion ou méthode, sans fiche)
L'avocat du diable