Création de produits : comment naissent les produits informatiques modernes

1. « Les gens ne naissent plus, on les cultive »

Eh bien, puisque vous êtes toujours là, poursuivons. « Et je vais vous montrer jusqu’où va le terrier du lapin » © 🐇

Laissez-moi vous expliquer comment se déroule le processus de développement d’un produit — nous allons parcourir les étapes du niveau le plus haut et global jusqu’au plus bas — l’écriture du code. Je pense que quelques découvertes intéressantes vous attendent…

On n’écrit plus les produits informatiques modernes, on les conçoit. On les assemble pièce par pièce à partir de bibliothèques, de frameworks, de logiciels et de produits tiers, ou l’on utilise carrément des services Internet distants payants ou gratuits 🧩.

Un produit moderne, c’est tout un zoo de technologies, de services, de solutions et de processus. Une partie du travail est effectuée par des humains, une autre est automatisée, et les 90 % restants sont carrément exécutés par des services cloud dans des data centers ☁️. Le monde n’est plus celui d’avant.

Mais la première chose que vous remarquerez — ce sont les changements permanents. Vous n’écrivez plus des programmes, vous y apportez des modifications.

2. Changements permanents

Vous arriverez au travail et rejoindrez une équipe de 20 personnes qui travaille sur le produit depuis 5 ans. Les utilisateurs ont actuellement accès à sa 7e version. Et votre tâche consistera à apporter des modifications à ce produit. De petites modifications, pour ne pas effrayer les utilisateurs actifs actuels.

Et ce ne sera pas simple, car le produit fonctionne déjà. Il a des clients, et ils paient de l’argent 💰. Il est donc hors de question de casser quoi que ce soit. Apporter des changements à un produit déjà en production est plusieurs fois plus difficile que sur un nouveau. Pour cela, il existe des normes spécifiques, des protocoles de migration et des utilitaires. Ça me rappelle tout de suite une blague :

Deux vieux amis se retrouvent : l’un est devenu mécanicien, l’autre — chirurgien… Chacun sa vie, ses soucis, ses joies… Ils se racontent tout, et la discussion en vient aux salaires. L’automécanicien dit : « Eh bien, je gagne 30 k par mois et j’en suis très content, et toi, combien ? ». Le cardiochirurgien dit : « Moi, c’est à peu près 100 k par opération… ». Le mécano s’y intéresse : « Étrange, pourquoi une si grande différence ? On fait pourtant la même chose, toi et moi — on change des pièces détachées ». Et le chirurgien lui répond : « D’accord, allons à la voiture, démarre… ». Le mécanicien démarre, le chirurgien ouvre le capot et lui dit : « Tu vois, le moteur tourne ? Remplace-le ! » 😂

Même si, par miracle, votre équipe a écrit le produit à partir de zéro pendant toute une année et ne l’a publié qu’ensuite, vous savez ce qui se passera après ? Si votre produit a du succès, le product owner voudra le faire évoluer. Publier une nouvelle version, ajouter une fonctionnalité. Ou au moins mener quelques expériences. Et vous savez ce qui s’ensuivra ? Des changements 🙈

3. Valeur du produit

Du point de vue du développement moderne, seule a de la valeur la portion de code déjà releasée, et la fonctionnalité dont les utilisateurs se servent. Si vous avez écrit du code, qu’il est stocké quelque part et qu’il tourne, mais que personne ne l’utilise, sa valeur est proche de zéro. C’est pourquoi tout code doit atteindre la production le plus tôt possible 🚀

Votre code doit passer par les étapes suivantes :

• ✔️ Vous l’avez écrit et vous vous êtes assuré qu’il fonctionne.
• 🔍 Votre TeamLead a fait la review et l’a ajouté à la branche principale dans Git.
• 🧪 Les tests durant la build du programme ont montré que vous n’avez rien cassé d’important.
• 🧩 Les tests d’intégration ont montré que le produit fonctionne comme prévu.
• 🛡️ Le testeur a vérifié ce code et a donné son feu vert pour la release.
• 📦 Ensuite, il faut construire une nouvelle version du produit et la releaser sur le serveur.
• 🐳 Il faut empaqueter la nouvelle version du produit dans des Docker Images et la releaser.
• 🗄️ Il faudra peut-être lancer des scripts de migration et apporter des modifications à la base de données et/ou à d’autres solutions tierces.
• 📊 Ensuite, il faut collecter les logs sur le serveur pour s’assurer que tout fonctionne comme prévu.
• ⏪ En cas d’incident, si vous avez cassé quelque chose, il faut rollback la build, restaurer l’état précédent de la base de données et ne pas perdre les actions réalisées par les utilisateurs pendant qu’ils utilisaient la version instable du produit.

Dans la plupart des entreprises, ces tâches sont désormais adressées : de nouveaux processus sont en place, des personnes dédiées ont été embauchées, des protocoles de sécurité spécifiques et des standards d’assurance qualité ont été introduits. Plus l’entreprise est grande, moins il s’écoule de temps entre l’écriture du code et le moment où il atteint la production et se transforme en valeur — commence à apporter un bénéfice aux gens.

Dans la plupart des entreprises, le code parcourt ce chemin en deux semaines. Cependant, certaines entreprises font des releases chaque semaine, voire chaque jour. Les cas les plus extrêmes — plusieurs fois par jour.

Le code écrit ne vaut rien. Seul le code qui tourne en production apporte de la valeur.