Soutenir l'innovation à grande échelle dans le domaine des applications
Les équipes décentralisées préservent leur vitesse grâce au contexte partagé
Lorsque les responsables de l'ingénierie parlent de « modernisation de la pile applicative », leur proposition se transforme souvent en liste d'achats pour leurs équipes.
Ils font du name-dropping en avançant une multitude de noms plus ou moins connus d'outils cloud-native, de pipelines CI/CD plus rapides ou de nouveaux assistants IA qui promettent de rédiger l'ensemble du code à votre place. Or, d'après mon expérience de CEO de RedwoodJS Inc., la modernisation de la pile commence souvent par l'adoption de nouveaux outils, mais la réussite dépend de la capacité de votre équipe à comprendre comment chaque élément s'articule et pourquoi ils sont importants.
C'est ce qui rend le processus de décentralisation si difficile.
Que vous cherchiez à mettre en place des équipes distribuées, des infrastructures modulaires ou des flux de travail fragmentés, la véritable difficulté réside dans le contexte. Tous les outils « modernes » du monde ne pourront vous aider à déployer des solutions plus rapidement ou plus sûres si les développeurs ne peuvent pas penser le système sur leur propre machine, si la sécurité et les produits ne sont pas alignés ou si les équipes chargées des plateformes constituent des goulots d'étranglement plutôt que de faciliter l'ensemble.
Chez RedwoodJS, le schéma est clair (de même que dans toutes les entreprises d'ingénierie avec lesquelles j'ai travaillé) : la décentralisation implique davantage que le déploiement de meilleurs outils. Elle nécessite une structure intentionnelle : c'est-à-dire des systèmes qui présentent le contexte approprié aux utilisateurs appropriés, en temps opportun.
Discutons de ce à quoi tout ceci doit ressembler en pratique.
L'innovation en matière d'applications, au-delà des outils
Imaginons que votre entreprise dispose d'équipes distribuées qui travaillent sur plusieurs fuseaux horaires (si ce n'est tous), de développeurs orientés fonctionnalités, d'une sécurité axée sur les risques, d'équipes chargées des plateformes qui prennent possession de l'infrastructure et d'une IA qui injecte du code, que vous soyez prêts ou non. Chacun de ses éléments dispose de ses propres outils, de ses propres motivations et de ses propres flux de travail.
L'hypothèse généralement poursuivie est que le déploiement d'outils plus récents remédiera à cette situation. Or, ils aggravent souvent la situation. Ce ne sont pas les capacités qui manquent réellement aux équipes, mais la clarté.
Le plus difficile dans le processus de modernisation ne se situe pas au niveau des compétences ou de l'échelle : il s'agit du fossé environnemental. Vous développiez autrefois sur les outils que vous aviez déployés. Aujourd'hui, l'intégration en continu réside dans le cloud, les développeurs travaillent à l'échelon local, la production s'effectue à un autre endroit et aucun de ces secteurs ne se comporte de la même manière. Vos développeurs travaillent à l'aveuglette et l'expression « ça fonctionnait sur ma machine » devient un de vos cauchemars quotidiens.
La véritable innovation consiste à éliminer les microfrictions afin que votre équipe puisse proposer ses produits dès aujourd'hui, plutôt qu'un jour prochain. Le processus commence par les efforts à déployer pour combler le fossé environnemental dont nous parlions plus haut, mais la véritable solution réside dans le contexte partagé.
La vélocité dépend du contexte : l'obstacle invisible du travail distribué
La vélocité n'est pas le fruit de meilleurs outils. C'est le résultat d'un processus décisionnel sans entraves.
Que se passe-t-il lorsqu'un développeur rédige du code et saisit une requête d'extraction ? Si l'entité évaluatrice manque de contexte (les raisons pour lesquelles la modification a été effectuée, les compromis qui ont été pris en compte et l'identité de l'utilisateur à l'origine de la requête), elle devra partir à la chasse de ce dernier. Ce mode opératoire ralentit l'ensemble du processus. De plus, dans les équipes distribuées, les personnes qui disposent des réponses pourraient même ne pas être en ligne au moment où vous avez besoin de leurs lumières.
C'est pourquoi nous avons commencé à mettre en place des Pull Requests (PR, requête d'extraction en français, une demande formelle d'intégration de code) en vidéo chez RedwoodJS.
Plutôt que d'écrire un pavé de texte ou d'espérer que quelqu'un lise le ticket Jira, le développeur enregistre une vidéo rapide pendant laquelle il capture son écran. Il passe en revue le code. Il explique le « pourquoi », pas seulement le « quoi ». Il discute des difficultés qu'il a rencontrées et des points sur lesquels l'entité évaluatrice devrait se concentrer. Cette procédure n'a rien de sophistiqué. Elle s'appuie sur un simple enregistrement d'écran, mais elle transforme une pull request froide et sans contexte en une discussion plus humaine.
Le contexte permet de préserver la vélocité, sans sacrifier la compréhension.
C'est au moment où le contexte disparaît que les raccourcis commencent à apparaître. Les développeurs commencent à se passer des tests du fait du manque de fiabilité de ces derniers. Une échéance s'approche à grands pas, alors ils brûlent les étapes. La boucle de rétroaction se rompt, la confiance s'écroule et la vélocité fait une chute vertigineuse. Les pull requests en vidéo, la répartition bien définie des responsabilités et les normes partagées constituent autant de moyens de lutter contre le désordre.
Lorsque le développement et la sécurité des applications ne sont pas alignés, personne n'y gagne
Lors d'une conversation que j'ai eue avec Trey Guinn, Field CTO de Cloudflare, dans le cadre de la série Au-delà de la pile applicative, nous avons discuté d'une statistique issue du rapport Cloudflare 2026 consacré à l'innovation en matière d'applications : 80 % des entreprises pensent que leurs équipes de développement et leurs équipes de sécurité sont parfaitement alignées.
Je vais répéter ici ce que je lui ai répondu ce jour-là : c'est n'importe quoi !
Les développeurs sont récompensés pour la production rapide de fonctionnalités et la sécurité est récompensée pour ses efforts de prévention des risques. Nous n'assistons pas ici à un alignement, mais plutôt à un parcours d'obstacles.
Le résultat est prévisible. La sécurité est perçue comme une taxe arbitraire sur le temps des développeurs, tandis que l'entreprise se retrouve avec des systèmes qui ne sont ni rapides ni sûrs. Au final, tout le monde y perd.
La solution réside dans la mise en place d'une équipe chargée des plateformes qui se comporte de la même manière que la Suisse.
Lorsque les équipes chargées de la plateforme travaillent, elles servent les équipes produit. Leur rôle n'est pas la gouvernance, mais la facilitation. Elles proposent des fondations sécurisées par défaut afin que les développeurs n'aient pas à choisir entre la sécurité et la rapidité. Elles font ainsi en sorte que la « bonne manière » de travailler soit également la plus simple. Enfin, elles prennent en charge les tâches fastidieuses et répétitives auxquelles personne d'autre ne veut même penser. Ces tâches incluent notamment la conformité. Lorsque la sécurité est incorporée à un stade précoce, par l'intermédiaire d'une infrastructure partagée et d'options par défaut, elle cesse d'être un goulot d'étranglement et commence à fonctionner de manière automatique. Les équipes chargées des plateformes sont dans la meilleure position pour ce faire, car elles intègrent les mesures de contrôle, d'audit et de cohérence sur l'ensemble des environnements, sans ralentir les équipes.
Lorsque l'équipe chargée de la plateforme devient un obstacle, c'est qu'elle a manifestement échoué. Toutefois, lorsqu'elles se comportent en tant que fournisseur de services (avec les développeurs comme clients), elles peuvent réaligner les motivations des équipes qui s'opposaient auparavant.
La répartition bien définie des responsabilités permet de sécuriser les options par défaut
Une fois que les équipes ont partagé le contexte, l'étape suivante consiste donc à définir les responsabilités de manière claire. Le contexte permet aux membres de vos équipes de comprendre pourquoi une décision a été prise. La prise de possession d'un processus permet de s'assurer que quelqu'un est responsable de la suite des événements. Sans cette procédure, même les développeurs les mieux intentionnés pourraient effectuer des actions non appropriées, pas par malveillance, mais par nécessité.
J'ai vu des développeurs transférer des bases de données de production entières sur leurs ordinateurs portables, car « l'étape de préproduction était inutile » et ils devaient trouver la solution à un problème de fuseau horaire. J'ai vu des notifications push porteuses de la mention « Tests en cours… 123 » adressées à de véritables clients. Enfin, j'ai également vu des stagiaires se connecter au système de production et supprimer des tables par accident, car personne ne leur avait dit de ne pas le faire. Ces signes précurseurs indiquent clairement la présence de systèmes conçus sans garde-fous.
Lorsque les responsabilités ne sont pas claires, le contexte disparaît et les membres de vos équipes font tout ce qu'ils peuvent pour se sortir d'une situation bloquante.
Les performances de votre IA dépendent de la structure de votre plateforme
L'innovation en matière d'applications doit permettre aux développeurs de ne jamais avoir à « tester en production » pour tout simplement effectuer leur travail. Cette conduite implique la mise en place de paramètres par défaut robustes, d'environnements plus sûrs et de limites claires autour de l'accès et des données. Elle implique également la nécessité d'investir à long terme (la « longue traîne ») dans une multitude d'aspects : la documentation, la journalisation des décisions, les conventions d'attribution de noms, etc. Tout ce qui permet aux nouveaux utilisateurs de s'adapter sans avoir à deviner ce qu'ils doivent faire.
C'est exactement sur ce type de structure que les systèmes IA devront s'appuyer pour être utiles. En centralisant les connaissances, en appliquant des normes et en prenant des décisions lisibles par la machine, les équipes chargées des plateformes jouent également un rôle essentiel dans la préparation des entreprises à l'IA.
L'IA peut rédiger du code rapidement. Toutefois, cette capacité ne sera que source de chaos si ce code est produit plus vite qu'il ne peut être examiné ou compris. Schémas contradictoires. Expérience utilisateur hétérogène. Connaissances tribales qui ne se mettent pas à l'échelle. Un assistant IA ne fera qu'ajouter de la complexité inutile s'il n'est pas en mesure d'expliquer à une nouvelle recrue pourquoi nous n'utilisons pas une certaine bibliothèque.
L'avenir appartient aux entreprises qui se structurent en faveur de la rapidité
Voici le principe que je souhaite que davantage de CTO suivent concernant l'innovation en matière d'applications. Posez-vous la question suivante : « Notre système est-il compréhensible ? ».
Pas « Avons-nous les meilleurs outils ? » ni « Utilisons-nous l'infrastructure la plus récente ? ». Tout simplement : « Un développeur nouvellement recruté peut-il devenir productif en un jour ou deux sans avoir à poser 50 questions ? ».
Si la réponse est non, votre pile n'a aucune importance. Vous échouez à atteindre le seul objectif qui compte vraiment : la vélocité.
L'innovation en matière d'applications implique de créer un environnement au sein duquel les équipes évoluent rapidement sans introduire de risques inutiles. Un environnement au sein duquel la rapidité et la sécurité ne sont pas antagonistes, et où le contexte est intégré à chaque étape des flux de travail. Il convient pour ce faire d'incorporer le contexte à ces derniers, d'aligner les motivations des équipes de développement, mais aussi des équipes chargées de la sécurité et de plateforme, sans oublier de bien définir les responsabilités (pas uniquement des systèmes, mais également des normes et des décisions).
Dans un monde décentralisé, le contexte est l'infrastructure et les équipes qui comprennent cette équation sont celles qui tireront leur épingle du jeu.
Cr éer une dynamique
La modernisation de vos applications marque une évolution continue dans la manière dont les équipes conçoivent, déploient et sécurisent leurs applications. Il ne s'agit pas d'un objectif ponctuel à atteindre. Pour soutenir cette dynamique, vous avez besoin d'une plateforme qui accélère la vélocité et met en place des garde-fous à chaque couche.
Que vous procédiez à la migration de systèmes existants, à la mise à l'échelle de microservices ou au développement d'applications AI-native, le cloud de connectivité Cloudflare soutient cette évolution. Grâce à sa plateforme unifiée alliant performances, sécurité, observabilité et des outils pour développeurs, Cloudflare réduit les frictions et permet aux équipes de bénéficier du contexte et du contrôle nécessaires pour progresser rapidement, sans compromettre la confiance ni augmenter les coûts.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Approfondir le sujet
Vous trouverez davantage d'informations sur la manière dont les entreprises modernisent leur pile applicative et leurs processus dans notre rapport Cloudflare 2026 sur l'innovation en matière d'applications.
Auteur
Peter Pistorius — @peterpistoriusree
CEO, RedwoodJS
Conclusions essentielles
Cet article vous permettra de mieux comprendre les aspects suivants :
La manière dont le contexte accélère les équipes décentralisées
Les raisons pour lesquelles l'alignement est essentiel à la sécurisation du processus de modernisation des applications
Le rôle des équipes chargées des plateformes dans la mise à l'échelle de la préparation à l'IA
Ressources associées
Rapport Cloudflare 2026 sur l'innovation en matière d'applications
La décentralisation est dangereuse (en l'absence de préparation)