Ce boulet que traînent les grandes boîtes

Quand on est une petite startup en recherche de rentabilité, on n'a qu'un objectif : sortir le plus vite possible et être rentable.

Ce contexte est très difficile, certains fondateurs ne ferment pas l'œil. Les fins de mois sont tendues, on compte les sous... C'est stressant !

Mais en contrepartie, cette situation a quand même du bon: la société est contrainte d'aller à l'essentiel et d'exécuter au mieux.

Une fois cette étape passée, on perd petit à petit cet état d'esprit et la société qui, autrefois, se permettait d'innover overnight, n'est plus qu'une pâle copie de toutes les grandes boîtes rigides avec des process à rallonge.

Tout ce qu'elle méprisait à l'époque, car cela représentait une machine archaïque qui ne servait pas les clients mais se contentait du minimum d'effort pour garder sa position dominante, elle l'est devenue aujourd'hui.

L'exécution à tout prix

Lorsqu'une startup essaie de prendre un marché, elle ne se refuse rien. Elle préfère faire, sortir petit, être imparfaite mais FAIRE. Plutôt que d'attendre de faire quelque chose de parfait mais qui sortira dans 2 ans, quand le marché sera devenu un océan rouge.

Ce mindset de hacker qui a juste envie d'expérimenter et de partager est probablement l'essence même de sa future réussite.

La société a les crocs, elle veut mettre en place quelque chose qui compte, et rapidement !

Je sais qu'on ne peut pas bâtir éternellement sur du quick and dirty, à un moment, il faut payer le prix de la dette technique. Mais il faut admettre que ça a du bon.

Quand une société prend plus de parts de marché, arrive à sortir une fonctionnalité supplémentaire, fait 1% mieux que son concurrent...

C'est stimulant et gratifiant !

Le problème vient uniquement au moment où les boîtes veulent passer en mode scale-up, qu'il y a beaucoup plus de recrutement et que, dans ce recrutement, on se retrouve avec beaucoup trop de devs au même moment, et on se doit de tout découper pour faire avancer tout le monde en parallèle.

À partir du moment où l'on doit interagir avec une grande équipe, attendre que les autres livrent avant de pouvoir envoyer nos changements, etc., on rentre dans un cadre où le fast-prototyping ne marche plus.

Vous connaissez mon amour pour les petites équipes . J'en parle souvent et pour cause, j'ai aussi connu les grandes équipes.

Je peux certifier qu'on y injecte plus d'argent qu'on en ressort.

Hugo Lassiège (CTO de Malt) en parle très bien :

Ils en parlent aussi dans Silicon Carne :

Et rappelez-vous ce que je répète toujours : la France a un décalage avec la compréhension et l'application de ces principes, mais ça finira forcément par arriver aussi chez nous.

Le problème du sur-process et la perte d'ownership

Aujourd'hui, je ne vous cache pas que les process dans les grandes sociétés sont une des raisons pour lesquelles il est impossible d'accélérer la cadence, malgré un ajout de nouveaux développeurs, malgré la création de nouvelles squads...

Mettez-y tout ce que vous voulez, ces sociétés sont bridées !

Parfois, l'organisation a du bon: apprendre les méthodologies et organiser permet de s'y retrouver toujours facilement.

Cependant, il y a des moments où l'on finit par prendre des décisions vraiment mauvaises : faire passer l'organisation avant le produit et la rentabilité.

Je sais que c'est un sujet qui fâche, mais à un moment donné, on est face à un choix qui a un réel impact sur l'avenir d'une société.

L'organisation et le process à tout prix, ça signifie souvent tuer toute forme d'innovation, de hacking constructif au sein d'une boîte. Car si on n'est pas en mesure de décider de comment on peut faire les choses et qu'on se remet à 100 % au process, alors il n'y a plus d'ownership, c'est-à-dire que les développeurs deviennent des exécutants, des bras.

Je peux vous citer un exemple concret :

On demande à mon équipe de prototyper la modération automatique de photos afin de décharger les opérateurs humains qui traitent des centaines de milliers de photos chaque mois.

On peut :

• soit faire quelque chose de smart avec des LLMs open-source (LLaMA-Vision) qui va décharger 80 % du travail et mettre ça en place en 2 jours ;
• soit faire une phase de prototypage avec des outils AWS Rekognition ou des process spécifiques de la boîte, qui demandera des semaines d'essais et de fine-tune.

À votre avis, qu'est-ce que la boîte a décidé ?

Réponse : le chemin le plus long.

Pas pour des raisons que je peux entendre : le coût, la mise en place, etc. Mais parce qu'on m'a dit : "Non mais tu sais, ici on a quand même un blueprint et il faut veiller à ne pas trop sortir de ça..."

Ok ! Si vous voulez. Après tout, ça a plus l'air d'être votre projet que le mien, vu qu'on n'a plus d'ownership étant donné qu'il faut se remettre au process.

Et ça, c'est pour moi le signe d'une boîte qui tue petit à petit l'innovation en interne et qui n'aura pour seul recours, en période de concurrence: le rachat du concurrent qui innove plus qu'elle, car c'est une capacité qu'elle a perdue au fil du temps.

Le pire dans tout ça, c'est que les 2 solutions auraient juste pu être séquencées pour que l'on ait déjà quelque chose en place, le temps de faire mieux. Mais au lieu de ça, la boîte refuse et passe par un process pour livrer dans quelques mois: BRAVO 👏👏

Je pourrais en parler des heures et vous citer le nombre de fois où c'est arrivé et que ça a desservi les sociétés : Google perd du terrain sur la recherche face à un ChatGPT, Meta perd du terrain sur les réseaux sociaux face à un TikTok qui arrive et innove, etc.

Ce n'est pas parce qu'un marché est bien établi à un instant T qu'on a le droit d'abandonner la culture de l'innovation.

L'innovation ne veut pas dire faire du cheap

La thématique qui divise le plus souvent la communauté des développeurs est celle du : Make money fast vs Make clean code.

Beaucoup de gens sont persuadés qu'il est impossible de faire les deux et qu'à partir du moment où tu veux faire du code propre, cela implique forcément que tu as renoncé à ta culture de hacker et d'innovation rapide.

Certaines personnes ont pourtant compris que l'un peut fonctionner avec l'autre, et je vais citer Michaël Azerhad : "La vitesse n'est pas opposée à la qualité de code, c'est la qualité de code qui t'amène la vitesse".

Faire du TDD, respecter les principes et méthodologies ne signifie pas tuer l'innovation. C'est souvent le manque de compréhension du sujet qui fait que les gens ont ce biais.

Car :

• premièrement, on ne va pas faire 100% de coverage mais chercher des critical paths ;
• deuxièmement, TypeScript ou autre langage fortement typé aura, à lui seul, désamorcé plusieurs situations avant même de devoir écrire des tests ;
• troisièmement, je vous recommande de garder une trace des répercussions lorsque les méthodologies ne sont pas respectées : combien de bugs, combien de temps pour résoudre, impact financier, etc.

De même, on ne doit pas s'interdire de mettre en place une feature sous prétexte que ça sort d'un blueprint qui nous dit :

• tu dois forcément utiliser telle techno ;
• tu dois forcément utiliser tel provider cloud...

Se créer des barrières à l'innovation, c'est ça, le vrai frein au développement. Alors qu'appliquer les méthodologies sur n'importe quel type d'implémentation, s'autoriser à livrer vite et bien, c'est se donner une chance de faire mieux que ses concurrents.