5 prises de risque audacieuses en développement logiciel que tout le monde jugeait folles… Jusqu’à ce qu’elles fonctionnent
Le développement logiciel repose sur des cadres familiers—Agile, Cascade, Scrum—tous des choix solides qui aident les équipes à livrer dans les délais et avec moins de surprises.
Mais parfois, nous sommes tellement habitués à ces sentiers balisés que nous oublions que les véritables percées surviennent souvent lorsque quelqu’un tente quelque chose qui semble insensé sur le papier. C’est risqué, certes, mais c’est là que se cachent généralement les plus grandes réussites.
« L’IA est vraiment douée pour accomplir 70% du travail plus rapidement », explique Alex Zajac, SDE & AI chez Amazon et créateur de la newsletter Hungry Minds. « Mais les 30% restants sont les plus difficiles : passer en production, éviter les hallucinations, et mettre en place des garde-fous d’évaluation. »
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Autrement dit, être audacieux dans le développement logiciel ne se résume pas à utiliser de nouveaux outils—il s’agit de faire le travail difficile et peu valorisant qui les rend vraiment efficaces.
La plupart des entreprises s’en tiennent au manuel habituel parce qu’il est considéré comme « sûr ». Personne n’est blâmé pour avoir joué la sécurité si une idée ne porte pas ses fruits dans le cadre d’un processus standard. Pourtant, selon une enquête McKinsey de 2023, les entreprises qui encouragent la prise de risques calculée ont 1,7 fois plus de chances de surpasser leurs concurrentes sur les indicateurs d’innovation.
Et même si nous savons que l’audace peut payer, il est étonnamment rare de trouver des environnements qui récompensent réellement l’expérimentation. Trop peu d’organisations encouragent explicitement la prise de risque sur les projets logiciels.
Les premiers adoptants, voire les véritables pionniers, ont souvent le privilège de définir les règles avant même que les autres sachent qu’elles existent.
Malgré toutes les peurs et les hésitations, certaines équipes ont sauté le pas et ont décroché des idées brillantes. Voici cinq stratégies qui semblaient d’abord excentriques—voire trop chaotiques—pour fonctionner.
Stratégie n°1 : L’ingénierie du chaos (Netflix)
Le « Chaos Monkey » de Netflix casse volontairement des systèmes en production pour tester leur résilience. On croirait rêver, non ? Pourtant, cette approche a permis à Netflix de maintenir une disponibilité de 99,99% tout en passant de 7 à plus de 230 millions d’abonnés.
« Nous avons réalisé qu’espérer la stabilité n’était pas une stratégie », a déclaré Kolton Andrus, ancien ingénieur chez Netflix. « En injectant régulièrement des pannes, nos équipes ont cessé de craindre les interruptions et ont conçu des systèmes plus robustes par défaut. »
L’élément clé était contre-intuitif : créer des défaillances contrôlées prévient en réalité les catastrophes. Les tests d’injection de pannes de Netflix ont révélé des points faibles qui seraient restés invisibles jusqu’à la survenue d’une vraie panne majeure.
À retenir : Commencez par une "journée de simulation" où vous testez des pannes dans un environnement non productif. Choisissez un service critique et introduisez des problèmes simples comme la coupure d’instances ou la rupture de connexions réseau. Notez ce qui casse et corrigez ces vulnérabilités avant qu’elles ne posent de vrais problèmes.
Stratégie n°2 : Déploiement continu (Flickr)
En 2009, alors que la plupart des entreprises effectuaient une mise en production mensuelle, la présentation de Flickr « 10 déploiements par jour » a bouleversé les esprits. Les équipes craignaient que des versions plus fréquentes entraînent le chaos, mais Flickr a constaté l’inverse : des sorties plus régulières ont en fait réduit considérablement les risques.
L’explication est à la fois simple et puissante : si l’on déploie 5 à 10 changements à la fois, l’identification des problèmes est aisée. Si l’on déploie 500 changements d’un coup après un mois, bonne chance pour retrouver l’aiguille dans la botte de foin.
Petits lots de déploiements = rayon d’impact réduit.
Les entreprises qui adoptent le déploiement continu constatent 70% de pannes en production en moins et une récupération 24 fois plus rapide en cas de problème, selon le rapport State of DevOps 2023. La pratique est depuis devenue la norme dans les entreprises technologiques de toutes tailles.
À retenir : Mettez en place une approche « fenêtre de déploiement » où les équipes augmentent progressivement la fréquence des mises en production. Commencez par passer des déploiements mensuels à hebdomadaires, puis bi-hebdomadaires, jusqu’à instaurer l’automatisation et la confiance nécessaires pour déployer plusieurs fois par jour. Concentrez-vous aussi sur la construction d’une suite de tests robuste qui s’exécute automatiquement avant chaque mise en production.
Stratégie n°3 : Modèle 100% télétravail (GitLab)
Avant la pandémie, la structure entièrement à distance de GitLab paraissait radicale. Pourtant, cela leur a permis de recruter les meilleurs talents dans le monde entier et d’imposer des pratiques de documentation irréprochables dès le premier jour.
Le manuel public de GitLab (aujourd’hui composé de plus de 15 000 pages) est devenu leur arme secrète, éliminant le problème du « je ne savais pas » qui touche tant d’équipes distribuées. Cette approche axée sur la documentation a permis aux nouvelles recrues de s’intégrer plus rapidement et a rendu la prise de décision plus transparente.
La documentation a une meilleure capacité d’évolution que la connaissance tribale. Voyez grand !
« Lorsqu’on ne peut pas demander une information à quelqu’un simplement en tapotant son épaule, on est obligé de tout documenter clairement », explique Darren Murph, responsable du télétravail chez GitLab. « Cela crée une résilience organisationnelle que les entreprises centrées sur un bureau n’atteignent que rarement. »
À retenir : Même sans être entièrement à distance, adoptez une pratique de documentation « remote-first ». Créez une base de connaissances centralisée pour toutes les décisions, processus et savoirs informels importants. Instaurez la règle que si quelque chose n’est pas documenté, cela n’existe pas. Passez en revue cette documentation chaque trimestre pour la maintenir à jour.
Stratégie n°4 : Développement basé sur le tronc (Etsy)
Etsy a abandonné les stratégies de branchement complexes au profit d’un modèle où chacun fusionne fréquemment dans la branche principale du code. Cette approche remettait en question l’idée reçue que les développeurs ont besoin de branches de fonctionnalités isolées pour être efficaces.
« Nous avons constaté que les branches de longue durée créaient en réalité un faux sentiment de sécurité », explique Daniel Schauenberg, ancien ingénieur chez Etsy. « En réalité, elles ne faisaient que retarder la douleur de l’intégration et générer des conflits plus importants lors de la fusion finale. »
Le développement basé sur le tronc a permis à Etsy de passer de 50 à plus de 2 000 développeurs tout en déployant plus de 50 fois par jour. Cette méthode a contraint l’équipe à concevoir de meilleurs tests automatisés puisque la branche principale devait toujours rester propre, et elle a éliminé le fameux « enfer de la fusion » trop courant avec les branches de fonctionnalités.
Alex a relevé une tendance similaire en parlant d’IA et de code fortement dépendant du contexte. « Les choses vraiment profondément liées à vos systèmes propriétaires... nécessiteront beaucoup d’intervention humaine, » a-t-il indiqué.
Dans les environnements très dynamiques, les équipes qui travaillent directement sur la branche principale doivent maîtriser la conception des systèmes et les compromis associés – car il y a moins de place pour se cacher derrière des branches de longue durée. Il ne s’agit pas seulement de pousser du code plus vite : cela amène les ingénieurs au plus près de la complexité réelle.
À retenir : Mettez en œuvre des commutateurs de fonctionnalités (« feature toggles ») pour masquer le travail en cours tout en fusionnant chaque jour dans la branche principale. Commencez avec une petite équipe de confiance pour instaurer la confiance dans la méthode. Fixez-vous l’objectif d’au moins un commit quotidien sur la branche principale et mesurez la réduction des problèmes d’intégration sur la durée.
Votre stratégie pour activer ou désactiver des fonctionnalités est cruciale pour ce que vous montrez à vos clients !
Stratégie n°5 : Open Source par défaut (Hashicorp)
Hashicorp a bâti une entreprise valorisée à un milliard de dollars en proposant en open source ses outils d’infrastructure clés comme Terraform, Vault et Consul. Contrairement aux modèles commerciaux logiciels traditionnels, cette stratégie a permis une adoption rapide et des contributions de milliers de développeurs dans le monde.
« Au début, beaucoup pensaient que nous étions fous de distribuer gratuitement notre meilleur code », explique Mitchell Hashimoto, cofondateur. « Mais nous avons constaté que l’adoption massive crée plus de valeur que ce que l’on perd en revenus de licences potentielles. »
Pour les développeurs individuels, choisir les bons outils enrichis par l’IA peut suivre la même logique. Alex explique qu’il a récemment choisi d’acheter Cursor Pro car « il me comprend ou comprend le style avec lequel je travaille. » Tout comme Hashicorp a misé sur la confiance et l’adéquation communautaire avec l’open source, les ingénieurs se tournent aujourd’hui vers des outils qui comprennent intuitivement leurs flux de travail – même si cela signifie choisir une option moins grand public.
Leur outil Terraform a récolté plus de 100 000 étoiles GitHub et s’est imposé comme la référence du secteur — ce qui aurait pris des décennies avec une approche propriétaire classique. L’entreprise monétise ses produits via des fonctionnalités dédiées aux entreprises, du support et des services hébergés tout en préservant la confiance d’une immense communauté de développeurs.
Conseil pratique : Identifiez les composants de votre logiciel qui pourraient bénéficier de l'implication de la communauté. Commencez par rendre open source une bibliothèque ou un outil utile qui ne constitue pas votre propriété intellectuelle principale. Mettez en place un processus de contribution qui facilite l'amélioration de votre code par des personnes extérieures et investissez dans une bonne documentation pour faciliter l'adoption.
Le fil conducteur
Ce qui relie ces stratégies, ce n'est pas seulement l'audace — c'est la prise de risque calculée avec des boucles de rétroaction serrées. Chaque équipe a mis en place des mécanismes pour tirer rapidement des leçons de ses erreurs et rectifier le tir.
Alex a évoqué comment l'IA modifie ce que cela signifie d'être développeur. « Nous ne sommes pas remplacés, » dit-il, « mais la fenêtre de responsabilités est en train de bouger. »
Certains pensent que les développeurs deviennent davantage des ingénieurs produits ; d'autres prédisent une bifurcation entre généralistes et spécialistes. Dans tous les cas, les stratégies de développement audacieuses ne réussissent pas seulement grâce à des outils innovants — elles réussissent quand les équipes sont prêtes à adapter leurs méthodes de travail, leurs rôles et leur manière de penser.
En repensant vos stratégies de développement, trouver les bons partenaires peut faire toute la différence. Vous pouvez par exemple envisager de travailler avec une entreprise de développement logiciel sur mesure ou une entreprise de développement logiciel nearshore.
Abonnez-vous à la newsletter The CTO Club pour plus de conseils, d’outils et de bonnes pratiques en développement logiciel.
