5 initiatives audacieuses de développement logiciel que tout le monde jugeait insensées — jusqu’à ce qu’elles réussissent
Le développement logiciel regorge de frameworks familiers — Agile, modèle en cascade, Scrum —, tous de bons choix qui aident les équipes à respecter les délais et à réduire les mauvaises surprises.
Mais il nous arrive parfois d’être tellement habitués à suivre ces chemins bien balisés que nous oublions que les véritables avancées surviennent souvent lorsque quelqu’un tente quelque chose qui semble insensé sur le papier. C’est risqué, certes, mais c’est généralement là que se cachent les grands succès.
« L’IA est vraiment très efficace pour réaliser 70 % du travail plus rapidement », explique Alex Zajac, ingénieur logiciel et spécialiste de l’IA chez Amazon, ainsi que créateur de la newsletter Hungry Minds. « Mais les 30 % restants sont les plus difficiles : les mettre en production, s’assurer qu’elle n’hallucine pas et mettre en place des garde-fous pour l’évaluation. »
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Autrement dit, l’audace dans le développement logiciel ne consiste pas seulement à utiliser de nouveaux outils : il faut aussi accomplir le travail difficile et peu glamour qui consiste à les faire réellement fonctionner.
La plupart des entreprises s’en tiennent au manuel habituel parce qu’il est perçu comme « sûr ». Personne n’est tenu responsable d’avoir fait cavalier seul si une idée n’aboutit pas dans le cadre d’un processus standard. Toutefois, selon une enquête de McKinsey réalisée en 2023, les entreprises qui encouragent la prise de risques calculés ont 1,7 fois plus de chances de dépasser leurs homologues du secteur en matière d’innovation.
Et même lorsque nous savons que l’audace peut être payante, il est étonnamment rare de trouver des environnements qui récompensent véritablement l’expérimentation. Trop peu d’organisations encouragent explicitement la prise de risques dans les projets logiciels.
Les premiers adoptants, voire les véritables pionniers, ont souvent la possibilité de définir les règles avant même que les autres sachent qu’elles existent.
Malgré toutes ces craintes et ces hésitations, certaines équipes ont fait un saut dans l’inconnu et ont abouti à quelque chose de remarquable. Voici cinq stratégies qui semblaient au départ originales — ou peut-être trop chaotiques — pour réussir.
Stratégie n° 1 : ingénierie du chaos (Netflix)
Le « Chaos Monkey » de Netflix désactive intentionnellement des systèmes en production afin de tester leur résilience. Cela semble insensé, n’est-ce pas ? Pourtant, cette approche a aidé Netflix à maintenir une disponibilité de 99,99 % tout en passant de 7 millions à plus de 230 millions d’abonnés.
« Nous avons compris qu’espérer la stabilité ne constituait pas une stratégie », a déclaré Kolton Andrus, ancien ingénieur chez Netflix. « En provoquant régulièrement des défaillances, nos équipes ont cessé de craindre les interruptions de service et ont construit par défaut des systèmes plus robustes. »
L’idée essentielle était contre-intuitive : créer des défaillances contrôlées permettait en réalité d’éviter les défaillances catastrophiques. Les tests d’injection de défaillances de Netflix ont révélé des faiblesses qui seraient restées cachées jusqu’à la survenue d’une panne majeure.
À retenir concrètement : commencez par une « journée de simulation » au cours de laquelle vous simulez des défaillances dans un environnement hors production. Choisissez un service critique et introduisez des défaillances simples, comme l’arrêt d’instances ou la coupure de connexions réseau. Documentez ce qui se casse et corrigez ces vulnérabilités avant qu’elles ne causent de véritables problèmes.
Stratégie n° 2 : déploiement continu (Flickr)
En 2009, alors que la plupart des entreprises effectuaient des déploiements mensuels, la présentation de Flickr intitulée « 10 déploiements par jour » a fait sensation. Les équipes craignaient que des mises à jour plus petites et plus fréquentes ne créent le chaos, mais Flickr a constaté l’inverse : des mises à jour plus fréquentes réduisaient en réalité considérablement les risques.
Le calcul est simple, mais puissant : si vous déployez 5 à 10 modifications à la fois, isoler les problèmes est relativement simple. Si vous déployez 500 modifications après un mois, bonne chance pour retrouver l’aiguille dans cette botte de foin.
Un lot de déploiements plus petit = un rayon d’impact plus limité.
Selon le rapport sur l’état du DevOps 2023, les entreprises qui adoptent le déploiement continu signalent 70 % de défaillances en production en moins et une récupération 24 fois plus rapide lorsque des problèmes surviennent. Cette pratique est depuis devenue la norme dans les entreprises technologiques de toutes tailles.
À retenir concrètement : mettez en place une approche par « fenêtre de déploiement », dans laquelle les équipes augmentent progressivement la fréquence des déploiements. Commencez par passer de déploiements mensuels à des déploiements hebdomadaires, puis deux fois par semaine, jusqu’à disposer de l’automatisation et de la confiance nécessaires pour déployer plusieurs fois par jour. Concentrez-vous sur la création d’une suite de tests robuste qui s’exécute automatiquement avant chaque déploiement.
Stratégie n° 3 : modèle entièrement à distance (GitLab)
Avant la pandémie, la structure entièrement à distance de GitLab semblait radicale. Pourtant, elle a permis à l’entreprise de recruter les meilleurs talents dans le monde entier et l’a poussée à instaurer d’excellentes pratiques de documentation dès le premier jour.
Le manuel public de GitLab (qui compte désormais plus de 15 000 pages) est devenu leur arme secrète, éliminant le problème du « Je ne savais pas » qui touche de nombreuses équipes distribuées. Cette approche axée sur la documentation a permis aux nouvelles recrues d’être opérationnelles plus rapidement et a rendu la prise de décision plus transparente.
La documentation s’adapte mieux que les connaissances tribales. Voyez grand !
« Quand on ne peut pas interpeller quelqu’un pour obtenir une information, on est obligé de tout documenter clairement », explique Darren Murph, responsable du travail à distance chez GitLab. « Cela crée une résilience organisationnelle que les entreprises centrées sur les bureaux atteignent rarement. »
À retenir : même si vous ne travaillez pas entièrement à distance, adoptez une pratique de documentation « à distance par défaut ». Créez une base de connaissances centralisée pour toutes les décisions importantes, les processus et les connaissances tribales. Établissez la règle suivante : si quelque chose n’est pas documenté, cela n’existe pas. Passez cette documentation en revue chaque trimestre pour la maintenir à jour.
Stratégie n° 4 : développement fondé sur le tronc (Etsy)
Etsy a abandonné les stratégies de gestion de branches complexes au profit d’un modèle dans lequel chacun apporte fréquemment des modifications à la base de code principale. Cette approche a remis en question l’idée largement répandue selon laquelle les développeurs ont besoin de branches de fonctionnalités isolées pour travailler efficacement.
« Nous avons constaté que les branches à longue durée de vie créaient un faux sentiment de sécurité », explique Daniel Schauenberg, ancien ingénieur chez Etsy. « En réalité, elles ne faisaient que retarder les difficultés d’intégration et créer des conflits plus importants lorsque les branches finissaient par être fusionnées. »
Le développement fondé sur le tronc a aidé Etsy à passer de 50 à plus de 2 000 développeurs tout en déployant plus de 50 fois par jour. Cette approche a obligé l’équipe à mettre en place de meilleurs tests automatisés, puisque la branche principale devait rester propre, et a éliminé le « chaos des fusions » bien trop fréquent auquel les équipes sont confrontées avec les branches de fonctionnalités.
Alex a relevé une tendance similaire en parlant de l’IA et des bases de code riches en contexte. « Les éléments qui sont profondément couplés à vos systèmes propriétaires… nécessiteront beaucoup d’intervention humaine », a-t-il déclaré.
Dans les environnements en évolution rapide, les équipes qui travaillent directement dans le tronc doivent comprendre en profondeur la conception des systèmes et les compromis, car elles ont moins de possibilités de se cacher derrière des branches à longue durée de vie. Il ne s’agit pas seulement de valider du code plus rapidement, mais aussi de rapprocher les ingénieurs de la complexité réelle.
À retenir : mettez en place des indicateurs de fonctionnalité pour masquer le travail en cours tout en envoyant quotidiennement les modifications vers la branche principale. Commencez avec une petite équipe de confiance afin de prendre en assurance avec cette approche. Fixez à l’équipe l’objectif d’envoyer des modifications vers la branche principale au moins une fois par jour et mesurez au fil du temps la réduction des problèmes d’intégration.
Votre stratégie d’activation des fonctionnalités est vraiment essentielle pour déterminer ce que vous montrez à vos clients !
More Articles
- Les 10 meilleurs outils de développement logiciel évalués pour 2026
- 10 Meilleurs Logiciels de Développement d’Applications en 2026
- 10 meilleurs outils d’IA pour la productivité des développeurs en 2026
- Les 10 meilleurs logiciels de développement d’applications mobiles évalués pour 2026
- 10 meilleurs outils de codage par IA en 2026
Stratégie n° 5 : logiciel à code source ouvert par défaut (Hashicorp)
Hashicorp a bâti une entreprise valorisée à un milliard de dollars en publiant sous licence à code source ouvert ses principaux outils d’infrastructure, comme Terraform, Vault et Consul. À rebours des modèles économiques traditionnels du logiciel, cette stratégie a permis une adoption rapide et des contributions de la part de milliers de développeurs dans le monde entier.
« Quand nous avons commencé, les gens pensaient que nous étions fous de distribuer notre meilleur code », raconte Mitchell Hashimoto, cofondateur. « Mais nous avons constaté qu’une adoption généralisée crée plus de valeur que ce que l’on perd en revenus potentiels issus des licences. »
Pour les développeurs individuels, choisir les bons outils enrichis par l’IA peut suivre une logique similaire. Alex a expliqué avoir récemment choisi d’acheter Cursor Pro parce que « cet outil me comprend vraiment, ou comprend le style sur lequel je travaille ». Tout comme HashiCorp a misé sur la confiance et l’adéquation avec la communauté grâce au code source ouvert, les ingénieurs se tournent désormais vers des outils qui comprennent intuitivement leurs flux de travail, même lorsqu’il s’agit de choisir l’option la moins répandue.
Leur outil Terraform a obtenu plus de 100 000 étoiles sur GitHub et est devenu une norme du secteur, ce qui aurait pris des décennies avec une approche traditionnelle à code source fermé. L’entreprise se rémunère grâce aux fonctionnalités destinées aux entreprises, à l’assistance et aux services hébergés, tout en conservant la confiance d’une immense communauté de développeurs.
Point à retenir : Identifiez les composants de votre logiciel qui pourraient bénéficier de la participation de la communauté. Commencez par publier sous licence libre une bibliothèque ou un outil utile qui ne constitue pas votre propriété intellectuelle principale. Mettez en place un processus de contribution permettant aux personnes extérieures d'améliorer facilement votre code, et investissez dans une documentation de qualité pour faciliter l'adoption.
Le fil conducteur
Ce qui relie ces stratégies, ce n'est pas seulement l'audace : c'est une prise de risque calculée, accompagnée de boucles de rétroaction étroites. Chaque équipe a mis en place des mécanismes lui permettant de tirer rapidement les leçons de ses erreurs et de rectifier le tir.
Alex a expliqué comment l'IA redéfinit ce que signifie être développeur. « Nous ne sommes pas remplacés, » dit-il, « mais la fenêtre glissante des responsabilités évolue. »
Certains affirment que les développeurs deviennent davantage des ingénieurs produit ; d'autres prédisent une bifurcation entre généralistes et spécialistes. Quoi qu'il en soit, les stratégies de développement audacieuses d'aujourd'hui ne réussissent pas uniquement grâce à des outils innovants : elles réussissent lorsque les équipes sont prêtes à adapter leurs flux de travail, leurs rôles et leur manière de réfléchir.
À mesure que vous repensez 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 de logiciels sur mesure ou une entreprise de développement logiciel à proximité géographique, par exemple.
Abonnez-vous à la newsletter de The CTO Club pour découvrir davantage de conseils, d'outils et de bonnes pratiques en matière de développement logiciel.
