J'ai vu un entrepreneur dépenser 150 000 euros et perdre dix-huit mois de sa vie à vouloir réinventer un moteur de recherche interne pour sa plateforme de gestion documentaire. Il pensait que l'innovation pure était la seule voie vers la différenciation. À la fin, son système était moins performant, plus lent et dix fois plus coûteux qu'une solution existante qu'il aurait pu intégrer en trois semaines. Il a oublié que le principe de Standing Upon The Shoulders Of Giants n'est pas une option pour les paresseux, mais une nécessité absolue pour ceux qui veulent réellement livrer un produit sur le marché avant que la concurrence ne les étouffe. En refusant d'utiliser les fondations posées par d'autres, il s'est retrouvé à creuser un trou au lieu de bâtir une tour.
L'erreur de l'originalité absolue face au Standing Upon The Shoulders Of Giants
Beaucoup de décideurs pensent encore que créer quelque chose de "propriétaire" à 100 % augmente la valeur de leur entreprise. C'est un mensonge qui flatte l'ego mais vide les caisses. Dans le secteur de la technologie ou du conseil, l'infrastructure est devenue une commodité. Si vous passez du temps à coder votre propre système d'authentification ou à rédiger des méthodologies de base qui existent déjà dans des cadres reconnus comme ITIL ou les normes ISO, vous ne créez pas de valeur. Vous accumulez de la dette technique et opérationnelle.
La réalité, c'est que les entreprises les plus performantes sont celles qui identifient précisément où se situe leur avantage concurrentiel. Tout ce qui ne fait pas partie de ce cœur de métier doit être emprunté, acheté ou adapté. Utiliser cette approche signifie accepter que 90 % de votre travail repose sur le génie des autres pour que vous puissiez concentrer vos 10 % d'effort restant sur l'innovation véritable. J'ai accompagné des startups qui voulaient tout faire "maison" ; elles sont aujourd'hui pour la plupart invisibles ou rachetées pour une fraction de leur investissement initial.
Pourquoi Standing Upon The Shoulders Of Giants n'est pas du plagiat
L'une des barrières mentales les plus tenaces que je rencontre est la peur d'être perçu comme un imitateur. On confond souvent l'usage de standards établis avec le manque d'imagination. C'est une erreur de jugement qui coûte cher. Le processus dont nous parlons consiste à prendre des théories, des frameworks ou des technologies éprouvées et à y ajouter une couche spécifique qui résout un problème nouveau.
L'illusion de la page blanche
La page blanche est l'endroit le plus dangereux pour un budget de développement. Quand vous commencez de zéro, vous héritez de tous les problèmes que vos prédécesseurs ont déjà résolus il y a dix ans. En ignorant les géants, vous vous condamnez à refaire leurs erreurs. Une entreprise de logistique que j'ai conseillée a voulu créer son propre algorithme de tournées sans s'appuyer sur la recherche opérationnelle existante. Résultat : des camions qui roulaient à vide 30 % du temps et trois ans de développement pour arriver à un résultat qu'un logiciel standard à 500 euros par mois dépassait largement.
Le piège de la personnalisation excessive des outils existants
C'est l'erreur classique du milieu de projet : on choisit une base solide, puis on commence à la modifier tellement en profondeur qu'elle devient méconnaissable. On pense bien faire en adaptant l'outil aux processus bancals de l'entreprise au lieu de faire l'inverse. Dès que vous modifiez le noyau d'une solution standard, vous perdez le bénéfice de la mise à jour et du support de la communauté. Vous n'êtes plus debout sur les épaules de personne, vous êtes en train de porter le géant sur votre propre dos.
Dans mon expérience, si vous devez modifier plus de 20 % d'une solution existante pour qu'elle réponde à vos besoins, c'est que vous avez choisi la mauvaise base ou que vos processus internes sont inutilement complexes. La stratégie consiste à rester le plus proche possible du standard. Le coût de maintenance d'une solution "custom" est souvent ignoré lors de la phase de lancement, mais il finit par absorber la quasi-totalité de la capacité d'innovation de l'équipe après seulement deux ans.
Comparaison d'approche : Le lancement d'une infrastructure de données
Imaginons deux entreprises, A et B, qui doivent mettre en place un système d'analyse de données clients pour se conformer aux nouvelles réglementations européennes.
L'approche de l'entreprise A (Le mythe de l'artisan) : La direction décide de construire son propre entrepôt de données en utilisant des serveurs locaux et en recrutant trois ingénieurs pour coder une interface sur mesure. Ils passent huit mois à débattre de l'architecture, six mois à sécuriser les accès et encore quatre mois à tester la cohérence des chiffres. Au bout de dix-huit mois, le système fonctionne, mais il est rigide. Chaque nouvelle demande de rapport prend deux semaines de développement. Ils ont dépensé 400 000 euros en salaires et matériel.
L'approche de l'entreprise B (Le pragmatisme) : L'entreprise B décide d'utiliser des services cloud établis et des outils de BI (Business Intelligence) du marché. Elle accepte de payer un abonnement mensuel conséquent. L'équipe se concentre uniquement sur la modélisation des données spécifiques à leur métier et sur la formation des utilisateurs. En deux mois, le système est opérationnel. Le coût initial est de 50 000 euros, incluant le conseil et les licences. Les analystes peuvent créer leurs propres rapports en quelques clics.
L'entreprise B a compris l'intérêt de Standing Upon The Shoulders Of Giants. Pendant que l'entreprise A luttait avec des problèmes de câblage et de base de données, l'entreprise B utilisait déjà ses données pour ajuster ses prix et gagner des parts de marché. La différence ne se joue pas sur la qualité du code, mais sur la vitesse de mise à disposition de la valeur.
Le coût caché de l'ignorance des standards de l'industrie
Il n'y a rien de plus frustrant que de voir une équipe talentueuse passer des nuits blanches sur un problème qui possède une solution documentée sur Stack Overflow ou dans des publications académiques depuis 1995. L'ignorance n'est pas une excuse, c'est une faute professionnelle. Utiliser cette stratégie de s'appuyer sur l'existant demande une culture de la veille permanente.
On ne peut pas se permettre de ne pas savoir ce qui se fait ailleurs. Trop souvent, le "syndrome du pas inventé ici" (Not Invented Here) paralyse l'innovation. Les ingénieurs aiment résoudre des problèmes complexes, mais le rôle du leader est de s'assurer qu'ils résolvent les bons problèmes. Si vous payez un expert 800 euros par jour pour qu'il recrée une bibliothèque de fonctions qui existe déjà en open source, vous gaspillez votre capital.
Comment identifier les bons géants sur lesquels s'appuyer
Choisir ses fondations est une décision stratégique qui engage l'entreprise sur des années. On ne s'appuie pas sur n'importe qui. Un mauvais choix de framework ou de partenaire peut devenir un boulet de plusieurs tonnes. J'ai vu des boîtes mourir parce qu'elles s'étaient basées sur une technologie propriétaire qui a cessé d'être supportée du jour au lendemain.
Voici les critères que j'utilise systématiquement pour valider une base :
- La taille et l'activité de la communauté : si personne n'a posé de question sur l'outil au cours des trois derniers mois, fuyez.
- La documentation : une excellente documentation est le signe d'un géant en bonne santé.
- La portabilité : est-ce que vous pouvez changer de fournisseur sans tout perdre ?
- La compatibilité avec les standards ouverts : évitez les prisons dorées.
Le processus demande une rigueur intellectuelle : il faut accepter de passer plus de temps à chercher et à évaluer qu'à produire. C'est contre-intuitif pour beaucoup de managers qui veulent voir des résultats immédiats, mais c'est le seul moyen d'assurer une croissance durable.
La vérification de la réalité
Soyons honnêtes : s'appuyer sur les travaux des autres n'est pas une solution miracle qui rend le travail facile. C'est même souvent plus difficile intellectuellement que de partir de zéro. Pourquoi ? Parce que cela exige que vous compreniez parfaitement les limites et la logique de quelqu'un d'autre avant de pouvoir construire votre propre structure par-dessus.
Si vous pensez que cela vous dispense d'avoir une expertise technique ou métier, vous allez vous fracasser. Au contraire, pour bien choisir ses "géants", il faut être soi-même extrêmement compétent. Vous devrez gérer des intégrations complexes, traduire des concepts d'un domaine à un autre et accepter que vous ne contrôlez pas 100 % de votre pile technologique ou méthodologique.
Le succès ne vient pas de l'idée originale, il vient de l'exécution et de l'assemblage intelligent. La plupart de ceux qui échouent avec cette méthode le font parce qu'ils ont été trop superficiels dans leur analyse. Ils ont pris une base sans en comprendre les failles. Ne vous attendez pas à ce que l'existant fasse tout le travail pour vous. Il vous donne simplement un point de départ situé 20 mètres au-dessus du sol. Le reste de l'ascension dépend uniquement de votre capacité à ne pas lâcher prise et à apporter la pièce finale qui manque à l'édifice. Si vous n'avez pas cette pièce finale, vous n'êtes pas un innovateur, vous n'êtes qu'un assembleur de second plan. Et le marché s'en rendra compte très vite.
