Architecte DevOps : concevoir des architectures qui accélèrent le delivery sans perdre la maîtrise

Une architecture réussie se mesure aussi à ce qu’elle permet aux équipes de faire simplement, rapidement et durablement. Livrer une application, la faire évoluer, la sécuriser, l’observer ou provisionner un nouvel environnement doivent pouvoir s’appuyer sur des pratiques et des standards conçus dès l’origine.

C’est précisément sur ces aspects qu’intervient l’Architecte DevOps : penser le delivery dans son ensemble, rapprocher développement et exploitation et construire un cadre technique suffisamment robuste pour accélérer sans sacrifier la qualité, la sécurité ou la capacité à évoluer.

Chez Inside, David Michel, Architecte DevOps et Expert Leader, intervient sur des enjeux d’architecture, de Cloud, d’automatisation, de CI/CD et de Platform Engineering. De ses missions clients à son rôle auprès des Insiders, il partage sa vision d’un métier où la technologie compte autant que la compréhension du contexte, des usages et des équipes.

David, quel est aujourd’hui ton rôle chez Inside en tant qu’Architecte DevOps ?

J’ai aujourd’hui une double casquette : Architecte DevOps sur les projets et Expert Leader métier au sein d’Inside. Sur le terrain, j’interviens sur des sujets d’architecture, de Cloud, d‘automatisation, de CI/CD ou encore de Platform Engineering. Mon rôle dépasse le fait de sélectionner des technologies ou de concevoir une architecture. En effet, j’interviens aussi et surtout sur les décisions qui vont structurer durablement la manière dont les équipes développent, déploient et exploitent leurs applications.

Cette vision vient aussi de mon parcours. J’ai commencé côté Ops comme Administrateur Système, avant de travailler sur la gestion de configuration logicielle puis sur des solutions d’Application Lifecycle Management. J’ai donc connu différentes parties de la chaîne et leurs contraintes respectives. Cela m’a rapidement convaincu d’une chose : on améliore difficilement le delivery si chacun optimise uniquement son propre périmètre.

L’enjeu pour moi est donc de conserver cette vision de bout en bout : comprendre l’objectif métier, les contraintes techniques et organisationnelles, les exigences de sécurité et d’exploitation, puis construire une architecture qui permette aux équipes de travailler ensemble dans de bonnes conditions.

Mon rôle ne se limite pas à la technique pure : il s’agit avant tout d’accompagner les clients dans leurs décisions structurantes pour construire des systèmes résilients, performants et réellement exploitables dans la durée.

En parallèle, mon rôle d’Expert Leader consiste à faire circuler cette expertise chez Inside : partager les retours d’expérience, structurer les pratiques et accompagner les Insiders lorsqu’ils rencontrent des problématiques complexes sur leurs missions.

Concrètement, qu’est-ce qu’un Architecte DevOps change dans un projet ?

L’Architecte DevOps agit d’abord comme un trait d’union entre les développeurs, les équipes Ops, la cybersécurité et les enjeux métiers.

Cela peut sembler évident, mais beaucoup de difficultés apparaissent justement lorsque ces sujets sont traités séparément. Une équipe de développement peut avoir parfaitement automatisé son intégration continue alors que la mise en production reste, elle, dépendante d’opérations manuelles ou d’une autre équipe. Chacun a optimisé sa partie, mais le flux global reste cassé.

C’est quelque chose que nous retrouvons régulièrement lorsque nous analysons une chaîne CI/CD : les principaux freins ne viennent pas forcément des outils eux-mêmes. Ils peuvent venir des responsabilités, des droits d’accès, des processus de validation ou simplement du manque de coordination entre ceux qui construisent et ceux qui exploitent.

Mon rôle consiste donc à regarder le cycle de vie complet de l’application, et non une succession de briques techniques : développement, tests, construction des artefacts, infrastructure, sécurité, déploiement, observabilité et exploitation.

L’autre principe important est d’intégrer les contraintes de production dès la conception. Attendre la fin du projet pour découvrir qu’une architecture est difficile à exploiter, à sécuriser ou à déployer coûte toujours beaucoup plus cher que d’avoir posé ces questions en amont.

L’objectif est ensuite de construire un cadre permettant d’automatiser et de standardiser ce qui doit l’être afin que chaque livraison soit reproductible, traçable et sécurisée. Livrer plus vite est intéressant ; être capable de le refaire régulièrement avec le même niveau de qualité l’est beaucoup plus.

Il ne faut jamais oublier que le DevOps, avant d’être une addition d’outils ou d’infrastructures, est d’abord une culture de la collaboration.

C’est aussi pour cela qu’un bon indicateur de performance n’est jamais uniquement la vitesse. Une équipe capable de déployer très souvent mais qui multiplie les erreurs, les corrections ou les retours arrière n’a pas réellement amélioré son delivery.

Le Platform Engineering est au cœur de ton expertise. Qu’apporte-t-il réellement aux développeurs et aux DSI ?

Le Platform Engineering répond à un problème très concret : éviter que chaque équipe reconstruise sa propre manière de développer, déployer et exploiter une application.

Quand plusieurs équipes travaillent chacune avec leurs pipelines, leurs scripts, leurs conventions et leurs processus, cette autonomie finit par produire beaucoup de complexité : les outils se multiplient, les pratiques divergent, la documentation devient difficile à maintenir et certaines connaissances restent concentrées chez quelques personnes.

L’objectif d’une plateforme interne est au contraire de mettre à disposition des développeurs, en self-service, des environnements, des pipelines, des services ou des composants déjà industrialisés. On peut y intégrer l’Infrastructure as Code, les standards CI/CD, les contrôles de sécurité, l’observabilité ou encore les mécanismes de déploiement.

Mais attention : le but n’est surtout pas d’ajouter une nouvelle couche technologique ou de bureaucratie. Une plateforme pertinente doit masquer la complexité qui n’apporte pas de valeur au développeur et lui permettre de se concentrer davantage sur son produit.

C’est là que le lien avec la Developer Experience (Devex) est important. Un développeur qui doit attendre une validation manuelle, rechercher pendant une heure comment provisionner un environnement ou comprendre pourquoi un pipeline opaque échoue perd du temps et du contexte. Une bonne plateforme doit supprimer autant que possible ces frictions.

Surtout, une plateforme doit être pensée comme un produit interne. Les développeurs, les Ops et les équipes qui l’utilisent en sont les utilisateurs. Il faut donc comprendre leurs besoins, maintenir un backlog, mesurer l’adoption, documenter les services proposés et faire évoluer la plateforme en fonction des retours terrain.

C’est une conviction que j’applique aussi à la CI/CD : lorsqu’une chaîne de delivery devient structurante pour des dizaines ou des centaines de personnes, on ne peut plus la gérer comme une accumulation de scripts maintenus ponctuellement. Elle devient un produit à part entière.

Pour la DSI, l’enjeu dépasse donc largement le confort des développeurs : plus de standardisation signifie également davantage de maîtrise, de sécurité, de reproductibilité et une capacité plus forte à faire évoluer le SI.

Quelles convictions guident tes choix d’architecture, au-delà des outils et des tendances ?

Ma première conviction est simple : je pars du contexte, des contraintes et de l’objectif avant de parler de technologie. Notre secteur est très sensible aux effets de mode. Une nouvelle technologie arrive, suscite beaucoup d’intérêt et peut rapidement devenir une réponse avant même que la question ait réellement été posée.

Or une architecture très moderne sur le papier peut devenir une mauvaise architecture si elle est trop complexe pour le besoin, si les équipes ne peuvent pas l’exploiter correctement ou si elle crée davantage de dépendances qu’elle n’en résout.

Je recherche donc des architectures simples à exploiter, sécurisées, documentées, évolutives et durables. Selon le contexte, cela implique aussi de travailler sur la réversibilité, les standards ouverts ou l’Open Source afin de préserver une capacité de choix et d’éviter une dépendance technologique non maîtrisée.

La sécurité doit également être intégrée dès la conception. L’enjeu du secure by design n’est pas d’ajouter des contrôles supplémentaires à la fin du pipeline : c’est d’intégrer autant que possible les exigences de sécurité dans les standards et les mécanismes automatisés afin qu’elles deviennent naturelles pour les équipes.

Enfin, je reviens toujours à une notion : la maîtrise. Maîtriser son architecture, c’est savoir de quoi elle dépend, ce qu’elle coûte, où sont ses risques et comment elle pourra évoluer.

C’est aussi pour cela que je m’intéresse beaucoup aux démarches comme Accelerate et aux métriques DORA. Elles permettent de sortir du ressenti pour regarder concrètement comment fonctionne le delivery : combien de temps faut-il pour faire parvenir un changement jusqu’à l’utilisateur ? À quelle fréquence livre-t-on ? Quelle proportion de changements génère un incident ? Combien de temps faut-il pour rétablir le service ? Quelle part du travail doit être refaite ?

L’objectif n’est pas de courir après les indicateurs. Il est de disposer de suffisamment de faits pour savoir où agir.

Il ne faut pas confondre vitesse et précipitation. Une architecture performante est celle qui permet aux équipes d’aller vite sans perdre la stabilité, la sécurité et la maîtrise de ce qu’elles délivrent.

Avec l’IA qui accélère aujourd’hui la production de code, est-ce que ces enjeux changent ?

L’IA ne remet pas en cause les principes du DevOps ou du Platform Engineering. Elle les rend, au contraire, encore plus importants. Si nous sommes capables de produire davantage de code ou de modifications en moins de temps, toute la chaîne située derrière doit être capable d’absorber cette accélération : tests, revue, sécurité, intégration, déploiement et observabilité.

Le risque serait de mesurer uniquement le gain individuel du développeur : « j’ai produit cette fonctionnalité plus rapidement ». Ce qui compte pour une organisation, c’est le temps nécessaire pour transformer cette production en valeur réellement disponible pour l’utilisateur, avec le niveau de qualité attendu.

Dans ce contexte, les plateformes ont un rôle important à jouer. Les standards, les tests automatisés, les environnements reproductibles ou les mécanismes de sécurité permettent de donner un cadre commun aux développeurs, mais aussi aux usages assistés par l’IA.

Pour moi, l’enjeu reste finalement le même : accélérer ce qui peut l’être sans déplacer la complexité ou le risque plus loin dans la chaîne.

En tant qu’Expert Leader métier, comment fais-tu grandir les Insiders et l’expertise collective d’Inside ?

J’accompagne les Insiders lorsqu’ils rencontrent des problématiques techniques complexes sur leurs missions, mais également dans leur progression et dans les orientations qu’ils souhaitent donner à leur expertise.

Pour moi, l’expérience acquise sur un projet ne reste pas enfermée dans ce projet. C’est pourquoi chez Inside, nous capitalisons sur les RETEX, d’organiser des échanges, des ateliers, des démonstrations, de faire de la veille, d’expérimenter de nouvelles approches et de confronter nos pratiques. Les certifications sont utiles mais la confrontation avec le terrain et le partage entre pairs le sont tout autant.

Cela bénéficie directement à nos clients : un Insider en mission n’est pas seul face à sa problématique. Derrière lui, il peut mobiliser des experts qui ont rencontré d’autres contextes, tester une idée, challenger un choix ou bénéficier d’un retour d’expérience provenant d’un autre projet ou d’une autre agence.

Être Expert Leader, ce n’est pas être celui qui possède toutes les réponses. C’est créer les conditions pour que chacun puisse progresser, partager son expérience et faire grandir à son tour l’expertise collective.