S’il y a une chose qui caractérise internet depuis ses débuts, c’est le partage.
La toile est un vrai vecteur d’échange des connaissances, et on retrouve particulièrement cette culture dans les communautés tech. Il n’est pas rare de voir les équipes de développement de Netflix, Etsy, Amazon, Google, AirBnB et d’autres ouvrir des espaces pour parler de leurs innovations.
C’est une très bonne chose, mais comme avec toutes les bonnes choses, il ne faut savoir être raisonnable. Certes, ces partages sont riches en enseignements et s’en inspirer permet de faciliter grandement la R&D. Mais ce ne sont pas des solutions miracles à tous les problèmes … pire que ça, ce sont des solutions à ce que j’appèle “des histoires de grandes personnes”. (hommage à un film culte)
Il existe une loi en ingénierie des systèmes appelée la loi de Gall. Elle dit la chose suivante :
🇺🇸 A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Ce qui donnerait en français quelque chose comme :
🇫🇷 Un système complexe qui fonctionne se trouve invariablement avoir évolué depuis un système simple qui fonctionnait. Un système complexe développé de A à Z ne fonctionne jamais et ne peut être patché pour le faire fonctionner. Vous devez recommencer depuis le début, en commençant par un système simple.
C’est assez radical, mais trop souvent vrai.
Dans le cadre de CTO as a Service, j’ai l’opportunité de voir pas mal de projets de startups, donc certaines qui viennent avec de grandes idées d’architecture par microservices, connectées à des API au top de l’innovation, avec du SSO et du machine learning et j’en passe … (je caricature mais vous voyez le profil).
Ces demandes sont souvent accompagnées de références pour légitimer leur demande : “Je veux un truc aussi simple et efficace que Google”, “Il faudrait faire une navigation comme AirBnB” ou autres “Sur Yelp la recherche fonctionne comme ça” …
Oui, les géants du net font comme ça, et ils ont raison de le faire. Mais s’ils font comme ça aujourd’hui c’est qu’ils ont rencontré toute une suite de problèmes auxquels ils ont du apporter une solution. C’est la somme de ces problèmes (et leurs solutions) qui les a menée à ce résultat.
Est-ce que la solution que proposent ces entreprises est la meilleure ? Probablement. On peut apprendre de ces équipes et les remercier d’avoir essuyé les plâtres. Mais leurs solutions ne sont pas les nôtres, car leurs problèmes ne sont pas ceux d’une entreprise qui lance un nouvel outil.
Quand on se lance, il faut savoir être un·e rêveur·se pragmatique, pour viser loin mais agir rapidement et avec un niveau de qualité adapté.
Les méthodes agiles proposent une large palette d’outils dans cette optique. Je pense par exemple à la matrice valeur effort qui met rapidement en évidence les innovations qui peuvent avoir un retour sur investissement rapide.
Car c’est ça l’essentiel quand on commence : créer de la valeur rapidement, pour créer de l’adhésion !
Le curseur n’est pas évident à placer entre respect des bonnes pratiques et sur-qualité, mais à moins que ce soit vraiment votre proposition de valeur, il est assez peu probable que vous ayez absolument besoin de blockchain, d’architecture microservice, de chaos monkey ou encore d’intelligence artificielle pour satisfaire vos premier·e·s client·e·s.
Et tout le mal que l’on peut vous souhaiter, c’est d’arriver au point où vous aurez vraiment besoin de ces solutions, mais en attendant, faites comme le recommande souvent Pascal Martin : “Choose boring technologies”.
-
PS : Je n’ai volontairement pas parlé de coût, mais il va de soi qu’on n’est pas capable des mêmes résultats quand on travaille avec un freelance à mi-temps que quand on a littéralement un campus de 12 000 personnes qui bossent sur nos produits.