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

1. « Les gens ne naissent pas, ils sont cultivés »

Bon, si tu es encore là, on continue. « Et je vais te montrer à quel point le terrier de lapin est profond » © 🐇

Laisse-moi te raconter comment se passe le processus de développement d’un produit — on va passer par toutes les étapes, du niveau global le plus haut jusqu’au code lui-même. Je pense que tu vas faire quelques découvertes intéressantes…

Les produits IT modernes ne sont plus écrits, ils sont créés. Ils sont assemblés à partir de bibliothèques, frameworks, logiciels tiers, ou même utilisent des services internet payants ou gratuits 🧩.

Un produit moderne, c’est tout un zoo de technologies, services, solutions et processus. Une partie du travail est faite par des humains, une autre est automatisée, et les 90% restants sont gérés par des cloud services dans des data centers ☁️. Le monde n’est plus le même qu’avant.

Mais la première chose que tu remarqueras — ce sont les changements constants. Tu n’écris plus simplement des programmes, tu y apportes des modifications.

2. Changements constants

Tu arriveras au boulot et rejoindras une équipe de 20 personnes qui bosse sur le produit depuis 5 ans. La version 7 est déjà disponible pour les utilisateurs. Et ta tâche sera d’y apporter des modifications. Des petites, pour ne pas effrayer les utilisateurs actifs actuels.

Et ce ne sera pas facile, car le produit est déjà en fonctionnement. Il a ses clients, et ils payent 💰. Donc, on ne peut rien casser. Modifier un produit déjà en production est plusieurs fois plus difficile que de créer un nouveau. Il existe des standards, des protocoles de migration et des utilitaires pour ça. Et voici une blague qui vient à l’esprit :

Deux vieux amis se rencontrent : l’un est mécanicien, l’autre est chirurgien... Chacun a sa vie, ses soucis, ses joies... Ils se racontent tout, et là, ils parlent des salaires. Le mécanicien dit : "Moi, je touche 30K par mois et je suis très content, et toi, combien ?". Le chirurgien cardiaque répond : "Environ 100K par opération...". Le mécanicien s’intéresse : "C’est bizarre, pourquoi une si grande différence ? On fait à peu près la même chose — changer des pièces". Et le chirurgien lui dit : "Viens voir la voiture, démarre-la...". Le mécanicien démarre la voiture, le chirurgien ouvre le capot et dit au mécanicien : "Tu vois, le moteur tourne ? Change-le !" 😂

Même si, par miracle, votre équipe a passé une année entière à écrire un produit from scratch, et l’a seulement ensuite lancé, tu sais ce qui arrivera après ? Si ton produit devient un succès, le propriétaire voudra le faire évoluer. Sortir une nouvelle version, ajouter des fonctionnalités. Ou au moins faire quelques expérimentations. Et tu sais ce qui suivra ? Des changements 🙈

3. La valeur du produit

Du point de vue du développement moderne, seule la valeur a le droit d’être considérée — c’est le code déjà déployé, et la feature que les utilisateurs utilisent. Si tu as écrit du code, qu’il est stocké quelque part, qu’il fonctionne, mais que personne ne l’utilise, alors sa valeur est proche de zéro. Donc, tout le code doit arriver le plus tôt possible en production 🚀

Ton code doit passer par ces étapes :

• ✔️ Tu l’as écrit et tu as vérifié qu’il fonctionne.
• 🔍 Ton TeamLead l’a revu et l’a intégré dans la branche principale dans Git.
• 🧪 Les tests lors de la build ont montré que tu n’as rien cassé d’important.
• 🧩 Les tests d’intégration ont montré que le produit fonctionne comme prévu.
• 🛡️ Le QA a vérifié ce code et a donné son accord pour la release.
• 📦 Ensuite, il faut construire une nouvelle version du produit et la déployer sur le serveur.
• 🐳 La nouvelle version doit être packagée dans des Docker Images et déployée.
• 🗄️ Peut-être qu’il faudra lancer des scripts de migration et faire des changements dans la base de données ou d’autres solutions tierces.
• 📊 Ensuite, il faut collecter des logs sur le serveur pour s’assurer que tout fonctionne comme prévu.
• ⏪ En cas de problème, si quelque chose a cassé, il faut faire un rollback, revenir à l’état précédent de la base de données, et ne pas perdre les actions faites par les utilisateurs pendant que la version instable était en ligne.

Dans la plupart des entreprises, ces tâches sont maintenant résolues : de nouveaux processus ont été mis en place, des spécialistes ont été embauchés, des protocoles de sécurité et des standards de contrôle qualité ont été instaurés. Plus une entreprise est grande, moins de temps s’écoule entre l’écriture du code et sa mise en production, où il devient une valeur — il commence à apporter des bénéfices aux gens.

Dans la majorité des entreprises, ce processus dure deux semaines. Mais il y a aussi des sociétés qui font des releases chaque semaine ou même chaque jour. Et des cas exceptionnels — plusieurs fois par jour.

Le code écrit n’a aucune valeur. La seule valeur vient du code qui tourne en production.