Équilibrer la rapidité et la durabilité dans l’ingénierie logicielle
La vitesse sans la durabilité casse les choses. La durabilité sans la vitesse bloque le progrès. Si vous voulez évoluer avec l’intention, vous devez maintenir les deux principes en place en même temps. Il ne s’agit pas de choisir l’un plutôt que l’autre. Il s’agit de faire en sorte que les deux fonctionnent en fonction de l’endroit où vous vous trouvez dans le cycle de vie du produit.
Beaucoup d’équipes se trompent. Elles poussent la vitesse des navires jusqu’à ce que les systèmes croulent sous la dette technique. Ou bien elles essaient de concevoir pour tous les cas d’utilisation futurs hypothétiques en même temps et perdent leur élan. Ni l’un ni l’autre ne sont évolutifs. Trop de complexité au départ retarde le retour d’information. Une trop grande vitesse imprudente favorise l’échec au moment où il est le plus important.
Ce qui fonctionne, c’est l’application d’un jugement situationnel. Au début de la vie d’un produit, la rapidité crée un avantage concurrentiel. Elle vous permet d’obtenir un retour d’information, une traction et une preuve de marché. Mais au fur et à mesure que l’utilisation augmente et que la complexité s’accroît, une architecture durable devient essentielle. Le rôle des dirigeants est de permettre aux équipes de faire des choix en temps réel en fonction du contexte réel, et non d’imposer la rigidité.
En tant que décideur, vous n’avez pas besoin de tous les détails techniques. Mais vous avez besoin de la vérité : vos systèmes ne peuvent aller plus vite que s’ils sont construits pour durer. Lorsque l’équilibre est atteint, vous obtenez des rendements composés importants, non seulement des lancements à court terme, mais aussi une résilience structurelle qui vous permet de faire des paris plus importants à l’avenir.
Exploiter les filets d’acier pour des prototypes évolutifs et intégrés
Lorsque vous construisez quelque chose de complexe, y compris un logiciel, vous voulez savoir à l’avance si les fonctions essentielles fonctionnent ensemble. C’est ce que fait un fil d’acier. Il s’agit d’une version fine mais complète d’une fonctionnalité clé qui s’étend sur toutes les couches du système, du front-end au back-end en passant par la base de données. Vous l’expédiez rapidement, vous l’utilisez pour constater les performances réelles de l’intégration et vous corrigez les points de rupture tant qu’ils sont encore bon marché.
Cette approche oblige à la clarté. Si quelque chose se brise dans le fil d’acier, vous le savez tout de suite. Elle renforce également la confiance. Une fois que le fil fonctionne de manière fiable, vous pouvez le développer sans avoir à tout remanier. Vous obtenez une accélération significative avec très peu de gaspillage.
Airbnb a opéré ce changement lors de l’extension des paiements internationaux. Au départ, son système de gestion des différentes devises était trop compliqué et n’évoluait pas bien. Ils ont changé de stratégie. Au lieu de cela, ils ont construit un processus de paiement propre, de bout en bout, comme un fil d’acier à travers leur pile. Ce processus a fonctionné, une fois mis en place, il a révélé plus tôt les cas limites, s’est adapté plus facilement et n’a pas nécessité de reconstruction complète. La plupart des équipes ont besoin de ce type de vérification avant d’investir massivement dans la croissance.
Si vous êtes responsable du produit, de l’ingénierie ou des opérations, approuvez ce type de raisonnement. Une fonctionnalité fonctionnelle de bout en bout, même si elle est minimale, apporte bien plus d’informations que l’assemblage de composants isolés. Il ne s’agit pas seulement de clarté technique. Il s’agit d’une visibilité stratégique. Et à long terme, cela permet de maintenir un lien étroit entre le développement et les résultats de l’entreprise.
Gérer intentionnellement la dette technique pour un progrès durable
La dette technique n’est pas le problème. L’ignorer l’est. Chaque équipe prend des raccourcis, certains intelligents, d’autres imprudents. Ce qui compte, c’est que vous suiviez la dette, que vous la choisissiez délibérément et que vous la nettoyiez avant qu’elle ne vous ralentisse. Les dirigeants qui considèrent toutes les dettes comme mauvaises passent tout simplement à côté de l’essentiel. Dans les environnements en évolution rapide, une dette calculée permet de gagner du temps.
Les équipes ont besoin d’espace pour avancer rapidement, en particulier lors de la validation d’un produit ou au début de sa croissance. Mais cette rapidité a un coût, et il est essentiel d’y prêter attention. Ce dont les ingénieurs ont souvent besoin, ce n’est pas de davantage de processus, mais d’une plus grande sensibilisation, en enregistrant les raccourcis pris, en les réexaminant dans les délais impartis et en sachant quels sont ceux qui comptent le plus.
X (anciennement Twitter) l’a appris de première main. L’entreprise s’est développée plus rapidement que prévu et le système n’a pas été conçu pour le supporter. Les pannes de leur plateforme sont devenues un signal que certaines décisions prises pour aller plus vite avaient atteint un prix inacceptable. Mais au lieu de réécrire leur infrastructure d’un seul coup, ils ont traité les problèmes les plus urgents au fil du temps, en se concentrant sur les goulets d’étranglement des bases de données, en renforçant la fiabilité et en procédant à un remaniement intentionnel. Il s’agissait d’une stratégie, et non d’une réaction.
En tant que dirigeant, vous devez insister sur la visibilité. Veillez à ce que les équipes tiennent un registre de la dette et lui accordent la même priorité qu’au travail sur les fonctionnalités. Soutenez un remaniement régulier, non pas comme un luxe, mais comme un investissement, au même titre que l’extension des opérations clients ou l’augmentation de la part de marché. Lorsque la santé technique est alignée sur les performances de l’entreprise, les équipes construisent plus vite et cassent moins. C’est là que vous gagnez en efficacité sans sacrifier la stabilité.
Application du principe du dernier moment responsable
Les décisions prises trop tôt ont tendance à être erronées. En particulier dans le domaine de la technologie, où les modes d’utilisation, les besoins des utilisateurs et les exigences en matière d’infrastructure changent constamment. Les équipes font leur meilleur travail lorsqu’elles répondent à des données réelles, et non à des suppositions ou à des hypothèses. C’est pourquoi reporter les décisions jusqu’au dernier moment est une bonne stratégie.
Ce n’est pas de la procrastination. Il s’agit de retarder la complexité architecturale jusqu’à ce qu’elle devienne nécessaire. Les équipes commencent simplement, surveillent l’utilisation réelle et n’investissent davantage que lorsque les données révèlent des contraintes. C’est ainsi que vous resterez léger, concentré et en phase avec ce qui est vraiment nécessaire.
Les dirigeants doivent créer un environnement dans lequel ce type de prise de décision est non seulement accepté, mais attendu. Laissez les équipes lancer des versions plus simples. Poussez-les à définir des plans d’urgence clairs pour la mise à l’échelle. Renforcez l’importance des données d’utilisation réelles. Lorsque cela devient une pratique, l’entreprise évite de gaspiller des ressources sur des problèmes qui n’existent pas et reste prête à faire face à ceux qui se présentent.
Investir sélectivement dans la qualité des composants critiques du système
Toutes les parties d’un système ne méritent pas le même niveau d’investissement en ingénierie. La qualité doit être ciblée. Certains composants génèrent directement des revenus, ont un impact sur la confiance des utilisateurs ou évoluent rapidement sous l’effet d’itérations constantes. D’autres ne le sont pas. Si vous traitez tout de la même manière, vous dispersez les ressources et ralentissez l’exécution.
Ce qui fonctionne, c’est la stratégie. Privilégiez une fiabilité maximale, la couverture des tests et une conception propre dans les systèmes importants, tels que les transactions des utilisateurs, les fonctions de sécurité, les services à forte charge et les modules qui changent fréquemment. Dans les domaines moins critiques, accordez plus de souplesse. Laissez les équipes agir rapidement dans les domaines où les risques d’échec sont faibles.
Slack illustre bien cette approche. Son équipe d’ingénieurs utilise un indicateur appelé Service Delivery Index for Reliability (SDI-R) pour évaluer la fiabilité des systèmes de base, en particulier la messagerie et la disponibilité de l’API. Ces systèmes affectent directement l’expérience de l’utilisateur et la confiance dans la plateforme. Slack fait preuve d’une plus grande rigueur dans ces domaines, tout en permettant à d’autres parties de la pile d’évoluer avec moins de frais généraux. Cet équilibre leur permet de conserver à la fois la fiabilité et la rapidité.
En tant que dirigeant, votre rôle est de favoriser cette concentration. N’exigez pas des efforts de qualité généralisés à l’ensemble de la pile. Au lieu de cela, exigez des produits et de l’ingénierie qu’ils vous expliquent clairement où la stabilité est la plus importante, et insistez pour qu’ils vous rendent des comptes. Il ne s’agit pas seulement de compter les bogues. Il s’agit de savoir quelles parties du produit l’entreprise ne peut se permettre de compromettre.
Moderniser les systèmes existants avec le modèle de la figue étrangleuse
Remplacer une plateforme existante en une seule fois est souvent impossible sans perturber les utilisateurs ou épuiser les ressources. Une approche plus durable consiste à moderniser pièce par pièce, en retirant progressivement les fonctionnalités de l’ancien système tout en maintenant les opérations de base. Bien menée, cette approche réduit les risques et laisse la place à un développement plus souple.
Pour que cela fonctionne, les équipes définissent des limites strictes. Elles isolent les fonctionnalités qui peuvent être développées indépendamment, les reproduisent dans le nouvel environnement et transfèrent progressivement l’accès des utilisateurs et les dépendances du système. Au fil du temps, la dépendance à l « égard des systèmes existants s’estompe jusqu » à ce qu’ils deviennent obsolètes et puissent être supprimés, avec un minimum de perturbations.
Shopify a utilisé ce modèle pour abandonner son architecture monolithique. Ses équipes ont progressivement remplacé les anciens composants par des services plus faciles à entretenir, ce qui a permis d’accélérer les cycles de développement, d’améliorer la fiabilité et de réduire la pression globale sur le système. Cela ne s’est pas fait du jour au lendemain, mais cela a fonctionné parce que la transition a été conçue pour s’aligner sur les priorités de l’entreprise plutôt que de les bloquer.
En tant que dirigeant, vous devez vous assurer que les limites du système et les étapes de mise en œuvre sont claires. Bien menée, cette méthode vous permet de mettre à jour la technologie tout en maintenant la continuité opérationnelle. Elle exige de la discipline et non une réécriture massive. Vous ne demandez pas aux équipes d’arrêter les livraisons, mais de concevoir un avenir plus facile, plus rapide et plus adaptable au changement.
Adopter une architecture sacrificielle pour une expérimentation rapide
Les systèmes en phase de démarrage n’ont pas besoin d’être permanents. Ils doivent évoluer rapidement, valider des hypothèses et fournir des informations. C’est la valeur de l’architecture sacrificielle, des solutions construites intentionnellement pour être temporaires. Lorsque l’objectif est la rapidité et l’apprentissage, construire quelque chose de léger que vous prévoyez de remplacer plus tard est souvent la bonne décision.
Cela ne signifie pas qu’il faille écrire un code bâclé. Cela signifie que vous donnez consciemment la priorité à l’infrastructure à long terme lorsque le produit lui-même est encore inconnu. Vous utilisez des cadres plus simples, des processus manuels ou des outils tiers pour valider la demande et recueillir des informations sur l’utilisation réelle. Une fois que le produit commence à se stabiliser, vous passez à la vitesse supérieure et commencez à concevoir pour la performance, l’échelle et la fiabilité, en vous appuyant sur des données pour étayer vos décisions.
Instagram a adopté cette approche à ses débuts. Il a lancé un simple monolithe. Cela lui a permis d’accéder rapidement au marché et de recueillir suffisamment d’avis d’utilisateurs pour accélérer la croissance. Mais lorsque la demande des utilisateurs a grimpé en flèche, ils ne se sont pas contentés de mettre à l’échelle la conception originale. Ils ont reconstruit les composants de base dans un but précis, en s’appuyant sur l’expérience réelle et non sur la spéculation.
Pour les dirigeants, l’important est de soutenir ce type d’architecture par des garde-fous. Demandez une documentation claire des décisions techniques. Veillez à ce qu’il y ait des déclencheurs précis pour la transition, qu’il s’agisse de seuils d’utilisateurs, de limites de volume ou de jalons commerciaux. Et faites bien comprendre qu’il n’est utile d’aller vite que si vous êtes prêt à remplacer ce qui n’est plus adapté.
L’architecture sacrificielle, lorsqu’elle est utilisée délibérément, donne aux startups et aux équipes de produits la vitesse et les données dont elles ont besoin pour évoluer. Le risque n’est pas de l’utiliser. Le risque survient lorsque personne ne se souvient qu’elle était censée être temporaire. Clarifiez les attentes dès le début et vous créerez une culture qui expédie rapidement, tout en restant prête à évoluer en toute confiance.
Dernières réflexions
La rapidité est importante. Il en va de même pour l’impact durable. Le véritable défi n’est pas de choisir l’un ou l’autre, mais de construire des systèmes qui soutiennent les deux sans compromis. Ce n’est pas de la théorie. C’est une discipline. Cela signifie qu’il faut investir là où c’est important, réduire la complexité là où ce n’est pas nécessaire et rester proche de la réalité au fur et à mesure que le produit évolue.
Les ingénieurs peuvent agir rapidement si l’architecture le permet. Ils peuvent livrer des systèmes durables si la feuille de route le permet. Mais l’orientation vient d’en haut. Les dirigeants qui reconnaissent l’équilibre, qui favorisent la rapidité tout en gardant à l’esprit la flexibilité et qui soutiennent l’itération en rendant des comptes, donnent à leurs équipes les bases nécessaires pour passer à l’échelle sans s’épuiser ni s’effondrer.
Vous n’avez pas besoin de connaître tous les détails techniques. En revanche, vous devez être en mesure de comprendre les compromis et de financer les bons. Lorsque la rapidité et la durabilité vont de pair, les entreprises ne se contentent pas de se lancer, elles se développent en toute confiance. C’est ainsi que vous gardez une longueur d’avance sans perdre en stabilité.
