🇬🇧 Click here to access the English version of this post
Chers CTO et tech leaders,
Au risque d'en choquer certains, je ne pense pas que le développement logiciel devrait encore être considéré comme une branche de l’ingénierie.
L’ingénierie consiste à utiliser des principes scientifiques pour construire des moteurs, des machines ou des structures. Les ingénieurs, qu’ils conçoivent le moteur d’un avion de ligne, une machine-outil sophistiquée ou un pont, doivent viser la perfection : une seule erreur peut avoir des conséquences considérables, parfois catastrophiques. Même dans le meilleur des cas, une bévue peut coûter très cher : les produits défectueux doivent être rappelés et corrigés, un processus qui mobilise du temps et du capital. Sans parler du risque de devoir redessiner tout le système, ce qui réduit drastiquement la marge d’un projet.
C’est pourquoi les ingénieurs sont formés et appliquent des méthodologies conçues pour éviter un maximum d’erreurs avant de livrer leurs produits. En ingénierie classique, le coût de l’erreur est extrêmement élevé.
À ses débuts, le développement logiciel obéissait aux mêmes principes physiques. Construire, exécuter et maintenir un logiciel coûtait très cher. Les développeurs étaient rares, programmer prenait du temps, et chaque mise à jour nécessitait une intervention de maintenance physique, sur site. À l’époque, le coût des erreurs en développement logiciel était donc lui aussi élevé. Mais le logiciel a changé. Il est devenu beaucoup plus rapide à construire et à déployer. Et même lorsqu’un bug système survient, les développeurs peuvent mettre à jour leur produit en quelques millisecondes, sans bouger de leur chaise, grâce à Internet.
À cause de ces transformations fondamentales dans la manière de concevoir et de mettre à jour un logiciel, le coût des erreurs en développement logiciel est devenu beaucoup plus faible.
Si le coût de l’erreur est devenu beaucoup plus faible, pourquoi continuons-nous à utiliser des méthodologies de gestion de projet et d’assurance qualité héritées de l’ingénierie classique ? Et si, au lieu de bâtir nos logiciels avec un état d’esprit préventif, nous adoptions un état d’esprit correctif ? Dans le développement logiciel, il est tout à fait envisageable de privilégier la correction des erreurs plutôt que leur prévention, en construisant des systèmes pensés pour l’adaptabilité et l’amélioration continue, plutôt que pour une perfection initiale illusoire. C’est le principe du « fail fast » : prototyper rapidement, mettre en production vite, en sachant qu’il y aura probablement des bugs ou des inefficacités, puis les identifier et les corriger activement au fur et à mesure.
Avec une telle approche, les développeurs peuvent accélérer considérablement les cycles de développement, sans être freinés par les pressions et contraintes liées à l’évitement systématique des erreurs. Cela favorise également un cycle d’apprentissage et d’amélioration continue, où les erreurs ne sont plus perçues comme des blocages, mais comme des opportunités d’optimisation.
Alors, je sais ce que vous pensez. Quand les développeurs vont trop vite dans les phases initiales de développement, ils négligent, ou ignorent, des problèmes qui seront ensuite longs et difficiles à corriger. Leur code est mal conçu. Il n’est pas commenté. Il devient presque impossible à maintenir, et encore moins d’y ajouter de nouvelles fonctionnalités. Ah, et je suis sûr que vous pensez aussi à la horde d’utilisateurs mécontents, prêts à se plaindre, voire à démolir le produit au point que les développeurs finissent par l’abandonner. Et vous auriez raison. Mais… est-ce vraiment toujours aussi dramatique ?
Tout d’abord, aller vite ne veut pas dire faire n’importe quoi. Un processus de développement rapide et bien structuré peut produire un logiciel aussi maintenable, voire plus, que celui issu de méthodes traditionnelles. La clé réside dans l’application des bonnes pratiques : conception modulaire, documentation appropriée, gestion rigoureuse des versions… autant d’éléments qui facilitent l’identification et la correction des problèmes. Dit autrement, si les développeurs conçoivent leur code dès le départ pour être fréquemment mis à jour dans le futur, et non comme une version définitive et figée, alors il sera beaucoup plus facile à maintenir.
Ensuite, même si personne n’aime utiliser un logiciel truffé de bugs, la perception et la fidélité des utilisateurs dépendent en réalité de nombreux facteurs qui vont bien au-delà des seules fonctionnalités immédiates. Prenons, par exemple, l’usage stratégique de la communication ouverte et de la transparence. Les entreprises peuvent impliquer activement leurs utilisateurs dans le processus de développement en leur expliquant clairement qu’ils interagissent avec une version itérative du produit, et que leurs retours et signalements de bugs contribuent directement à son amélioration. De plus, un support client efficace et réactif peut considérablement atténuer la frustration. Les utilisateurs pardonnent beaucoup plus facilement les bugs lorsqu’ils voient que l’équipe logicielle travaille activement à les corriger et à améliorer le produit, et que leurs préoccupations sont reconnues et traitées sans délai.
En conclusion, le développement logiciel a tellement évolué qu’il ne peut sans doute plus être considéré comme une simple branche de l’ingénierie traditionnelle. La réduction spectaculaire du coût de l’erreur, rendue possible par des cycles de développement rapides et la capacité de déployer des correctifs instantanément et à distance, remet en cause l’état d’esprit préventif classique et nous pousse à en adopter un plus correctif. Aujourd’hui, ce qui compte, ce n’est pas de construire le produit parfait du premier coup, mais d’être capable de corriger rapidement les problèmes et de le faire avec transparence.
Un processus de développement rapide mais bien structuré, qui respecte les bonnes pratiques, peut produire un logiciel aussi maintenable que celui issu de méthodes plus traditionnelles. Parallèlement, la transparence, l’implication des utilisateurs et un support réactif permettent d’atténuer la frustration, en créant un véritable sentiment de partenariat qui dépasse la simple relation utilisateur-produit. Adopter une approche « fail fast » peut sembler téméraire au premier abord. Pourtant, c’est aussi une adaptation pragmatique à l’évolution du développement logiciel, transformant les erreurs, autrefois perçues comme des coûts redoutables, en opportunités précieuses d’amélioration continue et d’innovation.
Mon approche, certes peu conventionnelle, de la construction de produits numériques pourra paraître risquée à certains. Mais dans un domaine aussi mouvant que le développement logiciel, c’est un risque qui vaut la peine d’être pris.