Le thème central qui a émergé au fil de la journée est le suivant :
Comment standardiser et automatiser les architectures pour les rendre résilientes, évolutives et gouvernables à l’échelle ?
De nombreuses présentations ont abordé, chacune sous un angle différent, cette problématique globale : de Kubernetes à grande échelle, l’industrialisation du CI/CD et approche SRE, plateformes internes pour développeurs, refonte technique des applications, résilience et sécurité « by design ». Pour chaque thème, nous mettrons en avant les solutions présentées, les leçons apprises, les bonnes pratiques recommandées, ainsi que les limites ou défis identifiés.
Déployer des clusters Kubernetes standardisés à grande échelle
Le coup d’envoi de la journée a été donné par un retour d’expérience sur le déploiement de Kubernetes à grande échelle, présenté par Rachid Zarouali (expert Cloud Native bien connu de la communauté). Son constat liminaire : «Aujourd’hui, déployer un cluster Kubernetes est facile, de nombreuses solutions existent… nous avons l’embarras du choix. Comment faire quand on veut déployer et gérer un grand nombre de clusters ? Quelles solutions utiliser ?»
En effet, si créer un cluster K8s est devenu trivial (que ce soit via un cloud public managé ou sur ses propres serveurs), gérer des dizaines ou centaines de clusters de façon cohérente et efficace pose d’autres défis. Rachid a partagé plusieurs projets menés pour relever ce défi, en comparant les outils et approches possibles, avec leurs avantages et inconvénients respectifs. L’objectif affiché était clair : montrer qu’avec la bonne stratégie, il n’est «pas plus compliqué» d’administrer deux clusters… que d’en administrer une centaine !
Concrètement, une solution ressort particulièrement pour standardiser le cycle de vie de multiples clusters : ClusterAPI (CAPI). Ce projet open source gravitant dans l’écosystème Kubernetes permet de définir déclarativement des “Cluster Specifications” (specs) que l’on soumet à un Cluster API provider chargé de créer ou modifier les clusters en se basant sur ces specs. L’Infrastructure as Code appliquée aux clusters, en quelque sorte. Rachid a illustré l’architecture de base de cette approche : un ingénieur DevOps formule la spec du cluster désiré (nombre et taille des nœuds, exigences de haute-disponibilité, etc.), puis via l’API ClusterAPI un cluster de management va instancier le cluster cible sur l’infrastructure choisie (cloud public, VMs on-premise…)
Schéma tiré de la présentation de Rachid Zarouali, illustrant l’architecture de base pour la gestion automatisée de clusters Kubernetes à grande échelle via ClusterAPI. Un ingénieur définit la “Cluster Spec” désirée, le ClusterAPI la prend en charge pour créer un cluster Kubernetes cible, que ce soit sur des machines virtuelles ou tout autre provider.
Cette approche permet de standardiser la création et la configuration des clusters (chaque nouveau cluster est créé d’après un modèle commun), tout en déléguant aux outils Cloud Native le soin de réaliser les opérations répétitives. En combinant ClusterAPI avec des pipelines GitOps (ex : ArgoCD) pour tenir à jour les specs, on obtient une véritable usine à clusters pilotable par le versioning Git.
Les leçons à retenir de ce talk : gérer un grand nombre de clusters Kubernetes devient viable à condition d’adopter une forte automatisation et des modèles standard. Les bénéfices incluent une cohérence accrue (tous les clusters sont construits selon le même patron), la réduction des erreurs manuelles, et la possibilité d’administrer une flotte de clusters comme une seule entité. Toutefois, l’automatisation à cette échelle nécessite un investissement initial non négligeable : choisir et mettre en place l’outillage (ClusterAPI ou autre), former les équipes à ces nouveaux workflows, et mettre en place un monitoring centralisé pour anticiper les problèmes (car avec 100 clusters, même peu de bugs isolés peuvent finir par survenir). Justement, l’orateur insistait sur l’importance de ne pas tout anticiper à l’avance mais d’avancer « petit à petit », en itérant, afin d’ajuster les outils et process au fur et à mesure plutôt que de chercher à tout prévoir théoriquement.
Extrait de la slide de conclusion d’un retour d’expérience sur la refonte d’une plateforme (voir section plus loin). On y voit par analogie des bonnes pratiques applicables à tout projet de transformation technique : avancer par petits incréments sans vouloir tout anticiper, outiller et monitorer pour détecter les problèmes au fil de l’eau, et éliminer progressivement les éléments “Legacy” une fois le nouveau système en place.
En somme, grâce à des outils comme ClusterAPI, il est possible d’industrialiser le déploiement de Kubernetes pour accompagner la scalabilité des plateformes Cloud Native. Cela confère une résilience supplémentaire (des clusters reconstruits à la volée en cas de panne) et une meilleure gouvernance (contrôle centralisé des versions de Kubernetes, des configurations de base, etc.), atouts précieux pour un DSI qui doit gérer une croissance rapide des services.
Industrialisation du CI/CD et démarche SRE à l’échelle
Passons maintenant à l’industrialisation des pipelines CI/CD et l’adoption des pratiques SRE (Site Reliability Engineering) à grande échelle.
Comment fédérer des centaines de projets applicatifs autour de processus d’intégration continue/déploiement continu unifiés, tout en améliorant la fiabilité globale ?
Sur ce thème, l’exemple marquant est celui d’un grand opérateur énergétique français qui a développé sa propre forge logicielle nommée “Placide”. Présenté par Sébastien Longo, ce retour d’expérience décrit comment, dans un groupe industriel fournissant des services essentiels, ils ont promu la posture DevOps et fait émerger une démarche SRE à l’échelle de l’entreprise. Placide vise à « fédérer plus de 400 projets sur une CI/CD uniformisée » en accord avec les principes SRE. L’initiative a nécessité de définir une vision commune, de la concrétiser via une plateforme outillée, et surtout de relever le défi de l’onboarding de centaines d’équipes sur cette nouvelle chaîne outillée. Une telle uniformisation apporte de grands bénéfices (mutualisation des outils, bonnes pratiques communes, indicateurs de fiabilité consolidés) mais implique aussi un accompagnement du changement en interne.
Le présentateur cadre les impératifs d’architecture : base GitLab, séparation des runners CI et CD, templatisation des pipelines, intégration des services d’usine (secrets, registre, qualité/sécurité du code, …). La plateforme Placide comme factory CI/CD regroupe des modèles de pipelines, exécuteurs segmentés, intégrations outillées et vues multi-projets pour piloter 400 + applications.
Sur le plan technique, Placide s’apparente à une chaine CI/CD “as a service” interne : dépôt de code, outils CI, orchestration de déploiement, gestion des artefacts, surveillance, etc.. ; le tout fourni aux équipes de développement via un ensemble d’outils et de règles communs. Si les détails de l’implémentation n’ont pas été entièrement dévoilés (solution maison oblige), on comprend que l’accent est mis sur le Everything as Code, l’intégration de la sécurité dans le pipeline (tests de vulnérabilités, règles de qualité, etc.), et la collecte d’indicateurs SRE (erreurs, disponibilité, performance) pour chaque service. Leçon apprise : pour embarquer 400+ projets sur une plateforme uniforme, la technique ne suffit pas. Il faut une vision partagée (ici, “DevOps partout, SRE partout”), du sponsoring pour faire adopter la solution, et une équipe dédiée à l’outillage qui traite ses “clients internes” (équipes dev) avec la même attention qu’un fournisseur SaaS le ferait pour ses clients externes. Les défis ont été nombreux, notamment gérer l’hétérogénéité initiale des pratiques, migrer des projets existants sans bloquer les livraisons, et former les développeurs à de nouveaux outils. Mais le résultat commence à payer : une base technique cohérente (la forge Placide) qui facilite la gouvernance (par exemple, les audits de conformité ou de sécurité sont simplifiés quand tout passe par un pipeline central) et qui améliore la résilience car une fois les bonnes pratiques SRE intégrées partout, l’organisation encaisse mieux les incidents (détection plus précoce, déploiements plus sûrs, etc.).
En parallèle, une autre session intitulée “Go Go Go (for ArgoCD, Golang, Golive)” a illustré une approche open-source pour industrialiser les déploiements d’environnements à l’échelle via GitOps. Thomas Boullier, François Tritz et Damien Gérard ont présenté comment ils exploitent la puissance d’ArgoCD (outil de GitOps), des Opérateurs Kubernetes en Go, et de la CI Tekton pour automatiser et maintenir à jour des environnements de développement sur OpenShif. L’accent est mis sur une approche “OpenShift-centric” on-premise, avec la conception d’un Opérateur custom en Golang pour simplifier le déploiement répété d’environnements dev/test. En pratique, cela signifie que la création d’un nouvel environnement (par ex. un namespace isolé avec toute la stack nécessaire) est déclenchée via Git (définition déclarative), prise en charge par ArgoCD, et les tâches spécifiques (création de ressources OpenShift, configurations) sont gérées par un contrôleur opérateur développé sur mesure. Cette chaîne automatisée permet de répliquer des environnements de manière cohérente et fiable, et de les “Go Live” en production de façon fluide.
Bonne pratique à retenir : l’utilisation de GitOps couplée à des opérateurs custom est un puissant levier pour scaler les opérations sans surcharger les équipes ; on encode dans l’opérateur le savoir-faire (pattern d’environnement) une fois pour toutes, puis chaque nouveau déploiement suit ce modèle automatiquement. La contrepartie est la complexité technique : il faut maîtriser le développement d’opérateurs Kubernetes en Go et la maintenance d’une chaîne CI/CD avancée (Tekton, ArgoCD). Néanmoins, pour qui en a les moyens, cette approche offre une grande flexibilité et réduit drastiquement les erreurs humaines dans le déploiement d’environnements, un point crucial pour la fiabilité (SRE).
Enfin, un aspect commun souligné tant par l’expérience Placide que par cette session GitOps est l’importance d’intégrer la sécurité le plus tôt possible dans le pipeline. Avoir un WAF en production ou des scans de vulnérabilités container c’est bien, mais détecter les failles en amont dans la chaîne CI/CD, c’est mieux. À ce titre, un outil comme Dependency-Track (présenté par Elisa Degobert) peut aider à prioriser les corrections de dépendances vulnérables en fonction de leur criticité exploitable. Une approche pragmatique pour ne pas se laisser déborder par des dizaines d’alertes de sécurité et concentrer les efforts là où il faut.
En résumé, l’industrialisation du CI/CD passe par la mise en place de pipelines uniformes, intégrés et “secures by design”. Que ce soit via une plateforme interne custom comme Placide ou via l’assemblage d’outils open-source (ArgoCD, Tekton, opérateurs…), le but est d’obtenir des déploiements fiables, reproductibles et pilotables à grande échelle. Pour les DSI, cela signifie moins de risques opérationnels (grâce aux contrôles automatisés) et une meilleure visibilité sur la production. Pour les développeurs, cela offre un cadre outillé qui accélère les livraisons tout en assurant une qualité constante.
Plateformes internes et expérience développeur homogène
Un thème récurrent fut également celui de la Developer eXperience (DevX) et des plateformes internes (Internal Developer Platforms). Dans de nombreuses organisations, standardiser les architectures ne concerne pas que la prod : il faut aussi outiller les développeurs pour qu’ils travaillent dans des environnements cohérents, efficaces et sécurisés, quelle que soit l’échelle de l’équipe ou du codebase. Engin Diri et Alexandre Nedelec ont ainsi proposé une session de fond intitulée « Internal Developer Platforms : choisir la bonne voie pour votre organisation ». Ils ont d’abord rappelé qu’au-delà du buzzword, les IDP sont devenues un élément essentiel des pratiques DevOps modernes, visant à rationaliser les workflows des developpeurs et accélérer les livraisons. Cependant, face à la pléthore de solutions possibles de l’open source (Backstage) aux offres SaaS (Port, Pulumi Cloud, etc.), les entreprises doivent prendre des décisions complexes pour élaborer leur stratégie IDP.
Leur présentation a fourni un cadre d’évaluation pratique : quels sont les composants essentiels d’une plateforme dev moderne ? Faut-il construire sa plateforme en interne ou s’appuyer sur un produit du marché ? Quels sont les patterns d’implémentation qui marchent, et les anti-patterns à éviter ? Autant de questions que les DSI se posent aujourd’hui, tant la promesse est attirante (une expérience développeur “5 étoiles” qui améliore la productivité et réduit le time-to-market) mais le chemin semé d’embûches (coût de développement d’une plateforme maison, intégration avec l’existant, risque de lock-in d’une solution SaaS, etc.).
Une IDP réussie doit apporter « les fonctionnalités essentielles aux développeurs » (environnements de dev prêts à l’emploi, déploiement en self-service, catalogues de services, outillage de sécurité, etc.) tout en s’alignant sur les objectifs business. Par exemple, une banque exigera de fortes capacités de gouvernance et conformité intégrées, là où une startup cherchera avant tout la vitesse de déploiement. Aucune solution unique ne convient à tous d’où l’importance de bien évaluer les options. Engin et Alexandre ont comparé les solutions open-source comme Backstage (très flexible, extensible, mais demandant un investissement pour l’opérer) et des solutions SaaS comme Port ou Pulumi Cloud (prêtes à l’emploi mais moins personnalisables). Ils ont aussi insisté sur la question Build vs Buy : développer sa propre plateforme peut donner un avantage sur-mesure, mais c’est un projet long terme qui mobilise une Platform Team dédiée ce n’est envisageable que si la taille de l’organisation le justifie. À l’inverse, une solution existante peut être déployée plus rapidement, au prix d’éventuels compromis sur les fonctionnalités ou l’indépendance.
En fin de compte, le choix de l’IDP “juste” dépend de la maturité DevOps de l’entreprise, de ses contraintes (sécurité, réglementation…) et de son écosystème technologique (cloud hybride, multi-cloud, on-prem, etc.). Quoi qu’il en soit, les IDP sont en passe de devenir un standard dans les grandes DSI : les gains en efficacité et en fiabilité qu’elles procurent ont été largement démontrés (notamment chez des géants du web pionniers en Platform Engineering), et les outils se démocratisent.
Pour illustrer concrètement la mise en œuvre d’une plateforme dev, un autre talk nous a menés sur le terrain des environnements de développement Cloud. “Développe sur un toaster grâce à Coder”, le titre amusant de la présentation de Melissa Pinon et Paul Vulliemin part d’un problème vécu par beaucoup de sociétés : « Vos développeurs se plaignent que leur PC est un grille-pain ? Que les environnements ne soient pas homogènes, et que la mise à disposition des postes est longue ? ». La solution proposée : les Cloud Development Environments (CDE), à savoir des environnements de dev distants, standardisés, accessibles à la demande. En l’occurrence, ils ont mis en œuvre la plateforme open source Coder pour orchestrer des environnements de dev hébergés sur Kubernetes, offrant à chaque développeur un IDE accessible via un navigateur mais tournant sur un container cloud. On peut ainsi travailler depuis n’importe quelle machine, même peu puissante (d’où le “toaster”, un PC poussif suffit pour afficher l’IDE, le gros du travail se faisant côté serveur). Le talk a présenté comment créer un environnement de développement dans un cluster Kubernetes à l’aide de Terraform, puis l’utiliser du point de vue du développeur. L’intégration avec des IDE populaires (JetBrains, VS Code) a été soulignée, de même que le fait que Coder est open source et gratuit, ce qui abaisse la barrière d’entrée pour l’expérimentation.
Avantages observés ? : des environnements homogènes pour tous les développeurs (fini les “ça marche sur ma machine”), une montée en quelques minutes au lieu de plusieurs jours pour installer/configurer un nouveau poste, et la possibilité pour les développeurs de passer d’un appareil à l’autre sans interrompre leur workflow. En termes de gouvernance, cela permet aussi au département IT de contrôler le catalogue d’images utilisées (versions de runtimes, outils préinstallés, etc.) et de renforcer la sécurité (le code source reste sur l’infra centralisée, non sur les laptops). Mais… ce modèle requiert une infrastructure Cloud puissante et fiable (ici un cluster K8s qui fait tourner potentiellement des dizaines d’environnements en parallèle), ainsi qu’une adaptation des usages (perte du mode hors-ligne, besoin d’une bonne connectivité). Néanmoins, pour des organisations distribuées ou en forte croissance, les CDE s’avèrent un outil précieux pour standardiser le poste de travail développeur et gagner en agilité.
En somme, qu’il s’agisse d’une Internal Developer Platform complète ou d’un service ciblé comme les environnements de dev distants, l’idée est de fournir aux équipes un cadre outillé unifié qui automatise les tâches répétitives et leur permet de se concentrer sur la valeur métier. Pour un décideur, investir dans de telles plateformes internes, c’est investir dans la productivité et la qualité à long terme. Les développeurs heureux (avec de bons outils) produisent un code plus fiable ; les processus standardisés réduisent les erreurs humaines et facilitent l’onboarding des nouveaux arrivants. La contrepartie est qu’il faut allouer des ressources à l’ingénierie de plateforme (une équipe outillage, de la formation) ; un effort qu’on peut moduler en adoptant progressivement des solutions externes prêtes à l’emploi selon les priorités.
Réussir une refonte technique sans (trop) en souffrir
Qui dit architecture résiliente et évolutive dit souvent refonte applicative à un moment ou un autre. Le retour d’expérience de Mickael Wegerich intitulé « Refonte technique : la formule magique pour ne plus en souffrir » le démontre. Mickael a partagé l’histoire de la refonte en profondeur d’une application critique, menée avec son équipe, et les enseignements qu’ils en ont tirés pour briser le cycle infernal des refontes à répétition. Il a commencé par planter le décor : identifier quand et comment justifier une refonte auprès des stakeholders (décideurs, métier); un point souvent délicat car une refonte est coûteuse et ne délivre pas de nouvelles fonctionnalités visibles. Dans son cas, ils ont su convaincre de la nécessité du projet en démontrant que l’architecture existante atteignait ses limites (dette technique trop lourde, incapacité à évoluer) et qu’à terme, ne rien faire coûterait plus cher que de refondre.
La “formule magique” évoquée dans le titre n’est pas un outil miracle, mais un mélange de bonnes approches : de l’organisation bien sûr (avoir une équipe dédiée, un plan itératif, un soutien du management) mais aussi la maîtrise des bons outils et bonnes pratiques techniques. Durant la refonte, son équipe a adopté une philosophie agile : découper le chantier en lots successifs livrables en production, afin de livrer de la valeur en continu au lieu d’un big bang risqué en fin de projet. Par exemple, ils ont pu déployer en parallèle la nouvelle API tout en gardant l’ancienne en fonctionnement, puis basculer progressivement les consommateurs vers la nouvelle. Ce strangling pattern a évité une interruption de service et a permis de tester la nouvelle architecture en conditions réelles petit à petit. « Y aller petit à petit » était d’ailleurs l’un des points soulignés en conclusion, de même que l’importance du monitoring tout au long du processus pour détecter les régressions ou problèmes de performance au fur et à mesure.
Parlons-en des résultats : Mickael indique qu’ils n’ont « jamais vraiment estimé » la totalité du projet au début (difficile sur une refonte complexe), mais en avançant incrémentalement ils ont réussi à tenir un rythme soutenable et à livrer un backend flambant neuf en un peu plus de 2 ans. Durant cette période, fait notable, ils ont eu très peu de bugs en production sur le nouveau code bénéfice direct de tests et d’une surveillance attentive sur chaque brique déployée. Le code legacy a pu être retiré progressivement et, au moment du talk, « le code refait est toujours utilisé » en production, preuve que la refonte a atteint son objectif de durabilité. Bien sûr, tout n’a pas été facile : « difficile de toujours penser à tout » note-t-il, concédant qu’il est ardu d’embarquer absolument tous les développeurs et parties prenantes dans la démarche au même niveau d’adhésion.
De plus, si la refonte du backend a abouti, le frontend doit maintenant subir le même sort , un rappel que la transformation n’est jamais terminée.
Enseignements clés : pour réussir une refonte, il faut (1) un découpage intelligent et une approche incrémentale, (2) un investissement outillage (tests automatisés, CI/CD fiable, monitoring en temps réel) pour sécuriser chaque étape, (3) impliquer les équipes dev pour qu’elles adhèrent au changement (former aux nouvelles technologies, montrer les succès intermédiaires), et (4) accepter que la refonte parfaite n’existe pas. On doit faire des compromis et tendre vers l’amélioration continue plutôt que la perfection. L’intervention de Mickael s’achève sur une note d’optimisme : en appliquant ces recettes, on peut « bâtir un socle technique solide et durable, capable d’évoluer sans tout remettre en cause ». Autrement dit, prévenir la prochaine refonte en concevant dès maintenant des architectures modulaires, évolutives, et en institutionnalisant les bonnes pratiques qui évitent l’accumulation de dette technique (revue de code, nettoyage régulier, documentation, etc.).
Pour les DSI/CTO, ce retour d’expérience offre un éclairage précieux : il est possible de s’attaquer à une refonte ambitieuse sans drame, à condition de créer les conditions propices (temps, outillage, talent) et de piloter par la valeur. Plutôt que d’attendre qu’un système devienne ingérable puis de tout jeter pour repartir de zéro, il vaut mieux anticiper et investir régulièrement dans l’entretien évolutif de l’application. Cela peut prendre la forme de refontes partielles ou continues, ce qui rejoint l’idée du Continuous Modernization prônée aujourd’hui. En un mot, construire la résilience à long terme d’un SI passe par des choix architecturaux judicieux et par la capacité à les remettre en question périodiquement sans tout casser : un équilibre délicat, mais atteignable avec méthode.
Résilience cyber et sécurité « by design » à l’échelle
La résilience n’est pas qu’une affaire d’architecture logicielle ou d’infrastructure c’est aussi la capacité à encaisser les chocs sur le plan cybersécurité. Plusieurs retours d’expérience ont traité de la sécurité à grande échelle, qu’il s’agisse de faire face à une attaque ou de gérer la sécurité au quotidien dans de multiples projets.
Le talk de Jean-Pierre Gil et Cyril Bouissou a particulièrement capté l’attention en revenant sur un scénario de crise bien réel : « De l’urgence à la résilience : sécurisation d’un site e-commerce après une attaque DDoS ». Ils ont raconté comment un de leurs clients, site marchand, a soudainement été paralysé par une attaque DDoS massive mettant à l’arrêt son activité en ligne. Chaos total, plus aucune commande possible le cauchemar de tout RSSI. Ils ont alors aidé ce client à rétablir le service en urgence en déployant une solution anti-DDoS cloud couplée à un WAF performant, capable d’analyser le trafic en temps réel et de bloquer automatiquement les menaces. Certaines des technologies employées intègrent des algorithmes pour distinguer le trafic légitime de l’attaque (par exemple via des empreintes spécifiques de botnets). Sur une slide édifiante, on pouvait voir la composition du trafic pendant l’attaque : plus de 40 millions de requêtes malveillantes reçues en 7 minutes, dont la quasi-totalité a été bloquée par le WAF, 0,7 million servies par le cache CDN (Cloudflare), et seulement ~35 000 ont atteint les serveurs en origine (serveurs applicatifs) à comparer à quelques milliers habituellement, preuve de l’efficacité du bouclier mis en place.
Extrait de la présentation de Jean-Pierre Gil et Cyril Bouissou quantifiant l’impact d’une attaque DDoS de grande ampleur subie par un client. En 7 minutes, plus de 41 millions de requêtes ont été émises, issues de plusieurs botnets. Grâce à la mise en place rapide d’un WAF cloud (couplé à un CDN), la quasi-totalité du trafic hostile a été bloquée automatiquement (zones orange et grises), et seulement une fraction infime a atteint les serveurs applicatifs (en vert)
Pour qu’une architecture soit résiliente, elle doit intégrer dès la conception des défenses en profondeur capables de se déployer rapidement. Ici, la présence d’un CDN/WAF a fait la différence entre une panne prolongée et une interruption limitée. Les présentateurs ont souligné qu’au-delà de la réponse technique, il a fallu aussi gérer la crise en termes de communication, et qu’un plan de continuité d’activité clair est indispensable (qui alerter, quelles décisions prendre en combien de temps). Après coup, le client a retenu de cet incident l’importance de tester régulièrement ses mécanismes de défense et d’envisager le “chaos engineering” (simuler des attaques pour éprouver le système et l’équipe).
La sécurité à l’échelle, c’est aussi être capable de gérer la multitude de vulnérabilités potentielles dans des dizaines de logiciels et leurs dépendances. Sur ce front, la solution Dependency-Track présentée plus tôt offre une aide précieuse. Elisa Degobert a rappelé qu’« il y a deux types d’entreprises : celles qui ont été hackées et celles qui ne savent pas encore qu’elles l’ont été » citation célèbre de John T. Chambers. L’idée est qu’il vaut mieux prévenir que guérir : mettre en place une démarche DevSecOps où chaque dépendance logicielle connue est suivie, où chaque CVE est évaluée et traitée. Mais dans la pratique, face à des centaines de librairies et une avalanche de failles publiées chaque mois, « c’est difficile de savoir par où commencer ». Faut-il corriger en priorité une vulnérabilité critique théorique mais difficilement exploitable, ou une faille moins sévère mais ouverte comme une porte béante ? C’est précisément à ce dilemme que Dependency-Track tente de répondre. En agrégeant les informations de vulnérabilité et en les croisant avec le contexte d’exploitation de l’application, l’outil aide à prioriser les efforts là où ils auront le plus d’effet. Pour un RSSI, ce genre de plateforme est un allié pour gouverner la sécurité applicative à l’échelle on passe d’une gestion artisanale des alertes à une approche systématique et mesurée, intégrée au pipeline CI/CD qui plus est.
Mentionnons également le retour d’expérience de Paul Pinault, qui bien que centré sur le développement en environnement blockchain, a mis en lumière la pression sécuritaire dans ces écosystèmes. En deux ans de développement d’une solution DeFi, son équipe a dû gérer une base de données dépassant 10 To, un flux de 100 000 événements par minute, et faire face à des attaques régulières liées à l’appât du gain (même pour quelques centimes). Cela les a contraints à écrire du code plus robuste, à mettre en place une surveillance proactive pour détecter les attaques en cours et y parer. La morale ici : quand la surface d’attaque s’élargit (beaucoup de données, de trafic, de services), il faut outiller l’infrastructure en conséquence (monitoring temps réel, alerting intelligent, etc.) et adopter une culture de sécurité partagée par les devs. On retrouve la notion de DevSecOps déjà évoquée, qui devient incontournable à grande échelle.
Enfin, au-delà des outils techniques, la WAX CONF a consacré une session entière à la dimension organisationnelle de la Tech. Renaud Decondé, dans un talk au ton volontairement provocateur (« Vous arrivez à organiser correctement les équipes Tech vous ???? »), a rappelé qu’il n’y a pas de solution miracle en matière d’organisation. On a beau appliquer les méthodes agiles à la mode, copier le modèle “Spotify”, ou empiler les frameworks (SAFe, LeSS…), « à la fin ce n’est jamais simple », car l’organisation doit avant tout répondre à des contraintes qui sont propres à chaque contexte. Son retour d’expérience, nourri de passages dans des grands groupes, des ESN et des scale-ups, suggère quelques principes : déjà, accepter qu’il n’y a « pas d’organisation parfaite » figée et que « l’orga doit changer aussi » dès que les contraintes changent (croissance, nouveau produit, nouvelles régulations, etc.). Ensuite, arrêter de croire à la pyramide idéale : il faut au contraire distribuer au maximum l’architecture comme l’organisation, laisser les “composants” (équipes) décider et s’auto-organiser dès que possible, c’est là « encore le mieux ». En clair, favoriser l’autonomie et l’adaptation locale plutôt que d’imposer un organigramme rigide top-down. Le message aux DSI/CTO est donc de se focaliser sur la mise en place d’un cadre (vision produit, principes d’architecture, rôles de base) tout en gardant suffisamment de souplesse pour que l’organisation se calibre d’elle-même. Cette notion d’équipe modulable rejoint l’analogie avec les architectures modulaires : de même qu’une architecture gouvernable est composée de briques indépendantes bien définies, une organisation efficace s’articule autour d’équipes indépendantes, alignées sur le produit, capables de reconfigurer leurs interactions sans tout casser. Pour la résilience globale de l’entreprise, c’est un facteur clé : une organisation trop figée résistera mal aux gros changements (marché, technologie), là où une organisation agile (au sens premier du terme) encaissera mieux en se réorganisant rapidement.
Vers des architectures durables et responsables
Concevoir une architecture « gouvernable à l’échelle », c’est de plus en plus prendre en compte des indicateurs environnementaux et éthiques, en plus des classiques indicateurs techniques ou financiers.
Ainsi, Arthur Kuehn a exposé une méthode simple en 3 étapes pour réduire la consommation énergétique d’un parc applicatif existant, même s’il n’a pas été conçu dès le départ avec des principes Green IT. La démarche proposée « Mesurer / Prioriser / Réduire » se veut « Simple (réalisable par 3 développeurs), Rapide (moins de 6 mois), et Efficace (avec des résultats concrets mesurés) ». En pratique, cela consiste d’abord à mesurer l’empreinte de vos applications (outils de mesure de conso CPU, de requêtes, etc., éventuellement en se basant sur des estimateurs de coût carbone par usage des ressources cloud). Puis à prioriser les applications ou composants à optimiser en fonction de leur impact et du coût/effort de correction. Enfin, à réduire effectivement cet impact via des optimisations ciblées (algorithmes plus efficaces, infrastructure adaptée à la charge, nettoyage de données inutiles, etc.). Ce retour d’expérience a montré qu’en s’y mettant à quelques développeurs motivés, on pouvait obtenir des gains tangibles sur des applications existantes sans bouleverser tout le SI. Par exemple en réduisant la fréquence de certaines tâches chronophages, on économise X% de CPU, ce qui en fin d’année se traduit par des kWh économisés et de la facture cloud en moins, tout en améliorant potentiellement les performances perçues.
Sur le volet infrastructures cloud, Elise Auvray de Scaleway a partagé les défis rencontrés pour mesurer l’empreinte environnementale du cloud. Collecter des données fiables, agréger des sources hétérogènes (consommation énergétique, émissions fabrication matériel, consommation d’eau des datacenters…), choisir des méthodologies d’analyse de Cycle de Vie (ACV) pertinentes tout cela s’est avéré non trivial. Son équipe a développé une Calculatrice d’Empreinte Environnementale pour leurs infrastructures, et l’un des messages était que la mesure est un prérequis crucial pour pouvoir améliorer : on ne peut réduire que ce qu’on arrive à quantifier. Cependant, attention aux données manquantes ou trompeuses : l’impact complet du numérique comprend le Scope 3 (fabrication des équipements, fin de vie) qui est souvent mal renseigné. Leur REX incite donc les DSI à se doter d’outils de mesure adaptés et à contribuer à améliorer la qualité des données environnementales.
Allant plus loin dans l’automatisation, Guillaume Michalag a présenté CloudAssess, une solution open source développée avec plusieurs partenaires, qui vise à automatiser de bout en bout l’Analyse du Cycle de Vie (ACV) des services cloud. Plutôt que de mener manuellement ces analyses (procédure lente et ponctuelle peu adaptée à la dynamique du cloud), CloudAssess propose une approche “LCA as Code” où l’on modélise les calculs d’impact et on les intègre directement dans les pipelines. Ils s’appuient sur des standards (ISO 14000) et mettent un focus particulier sur la qualité des données environnementales, en utilisant par exemple ResilioDB pour reconstruire des données cohérentes “from first principles” quand les données fournisseurs font défaut. Même si cela reste pointu, on voit se dessiner les outils de demain pour les responsables RSE et les architectes cloud soucieux de conformité réglementaire (la directive européenne CSRD va exiger dès 2025 des rapports extra-financiers précis). Le message stratégique est que la gouvernance à l’échelle inclura de plus en plus ces métriques de durabilité : il faudra outiller nos plateformes pour suivre l’empreinte carbone comme on suit déjà les coûts et les performances.
Enfin, au-delà de l’écologie, la dimension éthique & responsabilité englobe l’humain dans la tech. Sur ce point, le duo Magali de Labareyre / Laurent Grangeau a proposé un éclairage sur l’usage de l’IA dans le recrutement tech, en examinant le match parfait ou le cache-cache avec les biais. Si l’IA promet des recrutements plus efficaces (analyse rapide de CV, entretiens vidéo automatisés), elle comporte aussi des risques de reproduire voire d’amplifier des biais discriminants. Pour les DSI et RH, le défi sera de concilier l’apport de ces nouvelles technologies avec une gouvernance garantissant l’équité et la transparence. Ce sujet, bien que périphérique aux architectures IT, rappelle qu’automatiser à l’échelle n’est pas seulement un enjeu technique mais aussi sociétal.
Recommandations stratégiques
Cette journée en retours d’expérience concrets nous laisse un panorama des bonnes pratiques pour bâtir et faire évoluer des architectures standardisées, automatisées, résilientes et gouvernables à l’échelle. À destination des décideurs (DSI, CTO, RSSI), voici les principaux axes structurants qui se dégagent de WAX CONF 2025 :
Industrialisez et uniformisez vos fondations technologiques : qu’il s’agisse du déploiement d’infrastructures (clusters Kubernetes, environnements cloud) ou des pipelines CI/CD, investissez dans l’Infrastructure as Code et les approches déclaratives (GitOps, opérateurs) pour gérer votre SI comme un ensemble cohérent plutôt qu’une collection disparate. Des initiatives comme la plateforme Placide chez un grand compte démontrent qu’une forge logicielle commune peut supporter des centaines de projets tout en améliorant la fiabilité globale. Une telle standardisation facilitera la gouvernance (métriques uniformes, conformité centralisée) et la résilience (capacité à répliquer/reconstruire rapidement en cas de besoin).
- Misez sur les plateformes internes et l’automatisation du cycle de développement : la compétition pour attirer et retenir les talents IT se joue aussi sur la qualité des outils fournis en interne. Une Internal Developer Platform bien pensée, ou même des services ciblés comme des environnements de développement cloud, donneront à vos équipes les moyens d’être plus efficaces et cohérents. Cela réduit le Time to Onboard des nouveaux développeurs, uniformise les pratiques de déploiement, et limite les erreurs humaines. Comme l’ont montré plusieurs retours d’expérience, il est possible de s’appuyer sur des solutions open source matures (Backstage, ArgoCD, Terraform, etc.) pour construire progressivement cette couche plateforme plutôt que de tout coder from scratch. L’important est de commencer par les besoins les plus douloureux des développeurs (temps de setup, disparités d’environnements) et d’y apporter une réponse automatisée.
- Adoptez une culture DevSecOps et SRE, à grande échelle : la sécurité et la fiabilité doivent être traitées comme des enjeux de premier plan dès la conception et tout au long du cycle de vie. Cela signifie intégrer des outils comme Dependency-Track dans vos pipelines pour prioriser le traitement des vulnérabilités, automatiser les tests de sécurité, et sensibiliser continuellement les équipes. De même, embrassez les pratiques SRE (mesure des SLO, entraînement à la gestion d’incidents, déploiements automatisés et progressifs) non pas sur un ou deux projets pilotes, mais en les rendant systémiques. Comme le soulignait l’expérience Placide, diffuser cette culture à l’échelle de centaines d’équipes est un défi humain autant que technique. Il faut pour cela du leadership (évangélistes internes, formateurs) et du retour d’expérience concret pour montrer la valeur (temps de résolution d’incident divisé grâce à SRE, incidents de sécurité évités grâce à DevSecOps, etc.).
- Préparez-vous aux crises en bâtissant la résilience : les témoignages sur l’attaque DDoS l’ont rappelé, une architecture n’est résiliente que si elle est prête à faire face aux pires scénarios. En pratique, cela implique d’intégrer des solutions robustes dès le départ (WAF, CDN, plans de reprise automatisés) et de tester régulièrement ces mécanismes (exercices de charge, simulations d’attaques) pour s’assurer qu’ils fonctionnent le moment venu. Investir dans la résilience, c’est éviter des pertes colossales plus tard ; un message qui doit être compris au niveau de la direction générale également, car il en va de la continuité d’activité.
- Encouragez l’évolution continue plutôt que les refontes subies : le retour d’expérience sur la refonte réussie nous l’enseigne mieux vaut s’inscrire dans une logique d’amélioration continue de l’architecture que d’attendre l’accumulation d’une dette ingérable. En pratique, allouez du temps dans vos roadmaps pour des chantiers techniques réguliers, même de petite ampleur. Favorisez une architecture modulaire qui permet de remplacer un composant sans tout réécrire. Et si une refonte massive est inévitable, appliquez les principes vus plus haut (itération, outillage poussé, monitoring, etc.) pour en réduire les risques. L’objectif est de diminuer la douleur du changement pour les équipes comme pour les utilisateurs finaux en faisant évoluer le système par petits incréments.
- Intégrez les considérations durables et éthiques dans vos choix : la gouvernance à l’échelle implique désormais de rendre des comptes sur l’impact environnemental et social du SI. Commencez à mesurer quelques indicateurs (consommation énergétique des applications, empreinte carbone du cloud, diversité dans les équipes…) et fixez-vous des objectifs d’amélioration. Les outils commencent à émerger pour automatiser ces suivis, et les réglementations vont se renforcer (taxonomie verte de l’UE, CSRD, etc.). Le DSI de demain devra être autant capable de parler efficacité carbone que SLA. De même, restez vigilants sur l’usage éthique des nouvelles technologies (comme l’IA) dans vos processus : elles offrent des gains de productivité (revue de code automatisée avec IA, assistants de codage sur mesure) mais soulèvent des questions de gouvernance (biais, confidentialité) qu’il faut adresser par des règles claires et de la transparence.
- Enfin, soignez l’organisation humaine autant que l’architecture technique : on l’a vu, pas de recette magique, mais quelques principes directeurs émergent. Décentralisez dès que possible les décisions au plus près des équipes, responsabilisez-les sur leurs produits (mode product team), tout en donnant une vision et des contraintes claires au niveau central (sécurité, conformité, objectifs d’entreprise). Une organisation capable de se réagencer rapidement sera plus apte à tirer parti de l’automatisation et à faire évoluer ses architectures. À l’inverse, les structures trop rigides risquent de freiner ou d’annuler les gains que vos nouvelles plateformes/outils pourraient apporter. En bref, architecture modulaire + organisation agile = duo gagnant pour scaler sereinement.
Pour conclure, la WAX CONF 2025 a montré que la communauté tech regorge de solutions ingénieuses pour répondre aux défis de la scalabilité et de la résilience. Standardiser et automatiser, ce n’est pas déshumaniser ou brider la créativité au contraire, c’est libérer du temps et de l’énergie pour innover là où l’humain a le plus de valeur ajoutée, en laissant les machines et le code faire le reste. Aux DSI et RSSI de s’emparer de ces retours d’expérience, de les adapter à leur contexte, et de prendre dès aujourd’hui les décisions structurantes (outils, organisation, culture) qui prépareront leur SI aux défis de demain.
Pour résumer : “Automatisez tout ce qui peut l’être, standardisez tout ce qui doit l’être, et vous serez prêts à évoluer en toute gouvernance.”
Lionel GAIROARD
Practice Leader DevSecOps
