DevOps Experience Conf' 2026 : 6 enseignements clés sur la maîtrise des infrastructures

Le 15 octobre dernier, Kaliop organisait la première édition de la DevOps Experience Conf', consacrée aux enjeux de maîtrise des infrastructures et des opérations.

Deux talks et deux tables rondes ont rythmé la matinée, entre retours d'expérience, arbitrages techniques et questions du public. Du cloud souverain à l'IA dans les opérations, les sujets abordés recoupent les choix que les DSI, les équipes DevOps, les SRE et les architectes cloud ont à faire.

Nous en avons dressé les principaux enseignements dans cet article.

1. Le besoin passe avant l'outil

D'une session à l'autre, un même constat est revenu : un outil apporte de la valeur quand il répond à un besoin identifié.

Le talk Platform engineering : le pari financier et organisationnel de l'approche produit l'a posé d'emblée : une plateforme, ce sont d'abord des processus au service d'un besoin utilisateur, les outils viennent après. Dans l'analogie filée avec McDonald's, le besoin client, être servi vite et partout de la même façon, a défini les postes et les gestes avant les bornes et les écrans. Le portail en est la partie visible ; la plateforme englobe toute la machinerie cachée derrière.

Penser la plateforme comme un produit change aussi son adoption : elle se gagne au lieu de s'imposer. Le mindset produit reste déterminant, même sans product owner dédié, et ce sont les équipes utilisatrices qui la font évoluer dans le bon sens. Parmi les pièges cités :

• renommer l'équipe ops en équipe plateforme sans changer les processus,
• remplacer un outil par un autre sans gain pour les développeurs,
• imposer un portail complexe que personne n'a demandé.

La table ronde Observabilité : tout le monde en parle, qui en fait vraiment ? a fait le même constat : l'observabilité doit rester au service du produit, avec des métriques métier propres à chaque projet. Une étape reste souvent à franchir : la concevoir pour chaque population qui la consulte, du sponsor aux équipes techniques en passant par le marketing. L'alerte la plus utile, une baisse des ventes sur deux jours, reste la plus difficile à obtenir, car la plus éloignée de la technique. Les Core Web Vitals, indicateurs de performance perçue des pages, montrent aussi qu'une moyenne peut masquer de forts écarts : un temps d'affichage moyen du contenu principal (LCP) de 2,2 secondes peut cacher 10 secondes sur la page de paiement. D'où l'intérêt de tableaux de bord détaillés par page et par type d'utilisateur, centrés sur les parcours critiques. 

Encore faut-il connaître ce besoin : les équipes produit peinent souvent à décrire d'emblée les tableaux de bord attendus, d'où un travail par itérations.

Une plateforme ou un tableau de bord tire sa valeur de l'usage qu'il sert.
 

2. La souveraineté se joue à plusieurs niveaux, du stockage à l'inférence

La souveraineté dépasse la question de l'hébergement des données en Europe. Le talk Cloud souverain : à qui ça s'adresse et comment le déployer, en toute maîtrise ? a distingué trois questions :

• où sont les données, une question de localisation qu'un hyperscaler doté de régions européennes peut déjà régler,
• quel droit s'applique, ce que traite la qualification SecNumCloud de l'ANSSI (capital, droit, exploitants),
• quelle technologie est utilisée, un hébergement qualifié SecNumCloud pouvant reposer sur des briques Google ou VMware.

La question de fond a aussi évolué : au-delà de l'accès aux données, il s'agit de savoir si son service fonctionnera encore demain. En 2025, le procureur de la Cour pénale internationale a perdu l'accès à sa messagerie, hébergée chez un fournisseur américain, dans un contexte de sanctions américaines (Microsoft a indiqué ne pas être à l'origine du blocage). Finalisé en novembre 2023, le rachat de VMware par Broadcom s'est traduit par une refonte profonde du système de licences.

Les dépendances se cachent aussi dans l'administration de la plateforme, par exemple via un antivirus ou un EDR (outil de détection et de réponse aux menaces) installé au plus bas niveau du système, et dans les API : un hébergement SecNumCloud perd son intérêt si elles déversent tout vers un SharePoint chez Microsoft.
La table ronde Intelligence artificielle et opérations : jusqu'où l'intégrer ? a prolongé ce raisonnement jusqu'à l'inférence : stocker ses données en Europe puis les faire analyser par un modèle américain pose problème. Au regard des réglementations européennes NIS2 et DORA, un service d'IA s'évalue d'ailleurs comme n'importe quel autre service intégré à l'écosystème.

Contrepartie : les acteurs européens offrent une base de services solide, mais moins étoffée que celle des acteurs américains, ce qui implique des compromis.

La souveraineté s'évalue sur toute la chaîne, du stockage jusqu'à l'analyse des données.

3. La maîtrise passe par des standards ouverts

Garder la main sur ses choix suppose de pouvoir en changer. Le talk Cloud souverain a détaillé ce qui passe facilement d'un fournisseur à l'autre (stockage objet, Kubernetes managé, infrastructure as code, PostgreSQL), ce qui demande un effort, comme le passage de Kinesis à Kafka, et ce qui ne se transpose pas tel quel, comme Athena, sans équivalent direct chez les fournisseurs européens. Les intervenants en tirent quatre réflexes de portabilité :

• conteneuriser les applications,
• tout décrire en code, avec un modèle GitOps pour le déploiement,
• privilégier des moteurs et des API ouverts, comme PostgreSQL, S3 ou Kafka,
• s'appuyer sur le standard ouvert OpenTelemetry pour l'observabilité.

Un test sert de repère : en combien de temps peut-on redéployer ailleurs ce qui a été déployé, quelques heures, quelques jours ou quelques semaines ?

La table ronde Observabilité rejoint ce point : passer par OpenTelemetry pour la collecte permet de changer d'outil derrière. Et comme l'outil est souvent imposé dans les grands comptes, mieux vaut capitaliser sur les savoir-faire. La table ronde Intelligence artificielle et opérations applique la même logique aux modèles : utiliser chacun là où il est bon, sans se lier à un seul fournisseur.

Le standard a ses limites : une fonctionnalité centrale devra parfois être reconstruite à la main. À l'inverse, la migration peut révéler ce qu'un service managé masquait : en passant de Kinesis à Kafka, une équipe a découvert que les données envoyées n'étaient pas compressées, ce qui expliquait un coût élevé.

La portabilité se décide dès la conception.

4. Une transformation se construit par étapes

Côté cloud comme côté plateforme, les retours d'expérience décrivent une progression par étapes plutôt qu'un basculement d'un bloc.

La souveraineté s'atteint par paliers. Le talk Cloud souverain a pris l'exemple d'une plateforme dont les données sont hébergées en France, mais dont le cache, la sécurité et l'authentification passent par des solutions américaines : la démarche consiste à avancer brique par brique, la donnée d'abord, puis l'authentification, puis l'exposition. La migration suit la même logique, avec un inventaire qui distingue :

• les applications prêtes à migrer,
• celles à adapter, à cause d'un service manquant ou d'une contrainte de latence,
• celles devenues obsolètes, à faire évoluer plutôt qu'à déplacer telles quelles.

Viennent ensuite le cadrage de la cible, un planning par vagues et un retour arrière prévu avant la bascule. Une formule résume l'esprit : « ce qui ne sert plus ne déménage pas ».

Le talk Platform engineering défend la même approche : livrer vite une première version, puis itérer selon les retours des utilisateurs. Selon la notion de Thinnest Viable Platform (la plateforme minimale utile), une page wiki listant les services et la façon de les utiliser peut déjà constituer une plateforme. Le modèle de maturité de la CNCF (Cloud Native Computing Foundation) rappelle d'ailleurs qu'aucun niveau n'est bon ou mauvais en soi.

Avancer par étapes laisse aussi place à l'expérimentation : la table ronde Intelligence artificielle et opérations a défendu des périmètres d'expérimentation encadrés, quitte à accepter une part de déchet.

Qu'il s'agisse de migrer ou de bâtir une plateforme, le découpage en étapes rend le projet tenable.

5. Le coût d'une infrastructure se mesure au-delà de la facture

Chiffrer un choix d'infrastructure demande d'en recenser tous les postes. Le talk Cloud souverain en a listé quatre :

• la facture de run, sensiblement moins élevée chez un acteur souverain,
• le temps d'équipe pour maintenir les briques ajoutées soi-même,
• la migration, souvent l'occasion de faire évoluer l'application et de former les équipes,
• la transition, avec une période de double run, où l'ancienne et la nouvelle infrastructure fonctionnent en parallèle.

Les fournisseurs européens proposant moins de services managés, certaines briques doivent être opérées en interne, avec un coût de construction puis d'exploitation et des cycles de mise à jour qui s'accélèrent. Le cas d'un entrepôt de données (data warehouse) de 20 To illustre l'arbitrage : faute d'offre prête à l'emploi, l'équipe a assemblé un ClickHouse managé et un Grafana, avec plus de temps de mise en place mais un coût récurrent plus faible.

Le talk Platform engineering pose la question en termes d'investissement : prendre du temps maintenant pour en gagner ensuite. Selon le Puppet State of DevOps Report, cité pendant la conférence, 30 à 40 % du temps des développeurs serait perdu sur des environnements instables, du débogage ou l'attente de validations. Ce pari se mesure sur l'adoption, l'impact et la santé de la plateforme. La table ronde Observabilité rappelle aussi que tout conserver a un coût de stockage, et qu'héberger soi-même sa stack d'observabilité déplace le problème sans forcément le résoudre.

Ce calcul dépend du projet : une application au cycle de vie court, sans données sensibles, peut rester chez un hyperscaler.

Un choix d'infrastructure se chiffre sur toute sa durée de vie.

6. L'IA accélère l'analyse, la décision reste humaine

La table ronde Intelligence artificielle et opérations a décrit des usages déjà installés, et posé une limite. Les intervenants s'en servent au quotidien pour :

• analyser des logs et rechercher des solutions techniques,
• rédiger des rapports, notamment après un incident,
• vulgariser un sujet complexe pour une direction.

Le gain se mesure notamment sur le temps de résolution des incidents. Les équipes mènent plus de sujets en parallèle, mais la charge mentale reste la même. La table ronde Observabilité l'a aussi relevé : l'IA aide à trier le flot de données en plein incident.

Sur la dette technique, un intervenant a pris le contre-pied des idées reçues : l'IA aiderait davantage à la résorber qu'à l'aggraver, en rationalisant des piles d'applications legacy, en suivant le rythme des mises à jour ou en recréant une documentation jamais écrite. Encore faut-il distinguer le code jetable du code conservé et contrôler ce qui est produit. Certains laissent aussi dans leurs tickets des notes pour l'IA de la personne qui prendra le relais.

En production, l'IA dispose uniquement d'accès en lecture seule, verrouillés côté IA et dans les droits du compte. Ses résultats variant d'une exécution à l'autre pour une même tâche, un terraform apply (la commande qui applique les changements d'infrastructure) reste hors de son périmètre : elle aide à produire en amont un script, appliqué ensuite de façon déterministe. Sur un incident, elle accélère la première analyse, et l'humain intervient au moment le plus critique, celui de la remédiation.

Cette répartition a ses limites. À force de déléguer, se remettre à lire un script complexe sans aide deviendrait plus difficile. Et une personne qui applique une réponse d'IA sans réfléchir l'aurait fait avec Stack Overflow : c'est une question de pédagogie et de management.

La formule retenue pendant les échanges résume la posture : « faire de la délégation cognitive, pas de l'abdication cognitive ».

Cette première édition de la DevOps Experience Conf' confirme que, pour les équipes cloud et infrastructure, l'enjeu se déplace des outils vers la maîtrise des choix qui les entourent.
Les retours d'expérience partagés montrent que cette maîtrise se construit à partir du besoin, sur toute la chaîne de souveraineté, en s'appuyant sur des standards ouverts et par étapes, en chiffrant les coûts dans la durée et en gardant l'humain aux commandes face à l'IA.

Une exigence qui vaut à chaque étape, du besoin initial à l'exploitation.