La prémisse
En 2026, le DevOps est une discipline au statut particulier. Presque toutes les équipes d'ingénierie affirment le pratiquer. Beaucoup moins nombreuses sont celles qui possèdent réellement les propriétés opérationnelles que le terme promettait à l'origine : des délais de livraison courts, un faible taux d'échec des changements, une récupération rapide après incident et une culture où le déploiement n'est pas un événement trimestriel.
L'écart entre les deux s'est creusé avec l'arrivée des produits qui s'appuient sur l'IA. La cadence de déploiement qui suffisait à une application CRUD s'effondre lorsque le produit comporte un point d'accès servi par un modèle, susceptible de dériver, de se dégrader ou d'être limité en débit par un fournisseur en amont. Le DevOps qui fonctionnait ne suffit plus.
Cet article porte sur ce que la couche opérationnelle doit réellement livrer pour des produits qui intègrent des fonctionnalités d'IA — et sur la façon dont l'IA elle-même transforme le travail DevOps.
Deux facteurs ont étiré la couche opérationnelle en même temps
La cadence et la surface d'exposition ont toutes deux augmenté. Le DevOps qui suffisait a cessé de suffire.
Le premier facteur est la cadence. L'ingénierie assistée par l'IA a comprimé le temps entre l'écriture d'un changement et le moment où il est prêt à être livré. Des équipes qui mettaient une semaine à intégrer un changement non trivial l'intègrent désormais en une journée. Le pipeline qui encadrait la cadence plus lente devient le goulot d'étranglement de la nouvelle.
Le second facteur est la surface d'exposition. Les fonctionnalités d'IA ajoutent des dépendances en amont — fournisseurs de modèles, systèmes de récupération, bases vectorielles, harnais d'évaluation — qui n'existaient pas dans une application web classique. Chacune d'elles peut défaillir d'une manière que le reste de l'application doit gérer avec élégance. La couche opérationnelle doit toutes les connaître.
Ensemble, ces deux facteurs ont ramené le DevOps d'une discipline d'arrière-plan au centre de l'ingénierie. Les équipes qui n'ont pas investi en conséquence produisent davantage de pannes au rayon d'impact plus large. Celles qui l'ont fait livrent plus, plus vite, avec une réponse aux incidents plus sereine.
Pipelines, infrastructure-as-code, observabilité, réponse aux incidents
Chez SDEN, la couche opérationnelle s'articule autour de quatre pratiques. Les pipelines : chaque changement est compilé, testé et déployé par la même mécanique, sans étape manuelle dépendant du portable de quelqu'un. L'infrastructure as code : chaque environnement est reproductible à partir du dépôt, y compris la structure des secrets (pas leurs valeurs). L'observabilité : métriques, journaux et traces de chaque composant, avec des tableaux de bord détenus par l'équipe qui détient le composant. La réponse aux incidents : des runbooks écrits, une rotation de garde humaine et des revues post-incident qui produisent de réels changements.
Ces quatre pratiques constituent le socle minimal. C'est aussi là que la plupart des missions enlisées révèlent des lacunes — généralement dans l'observabilité et la réponse aux incidents, parce que les pipelines et l'IaC sont visibles tandis que les deux autres ne le deviennent qu'au moment des pannes.
Des propriétés opérationnelles sans lesquelles un produit d'IA ne peut pas être livré
Un produit qui dépend d'un modèle en production a besoin de propriétés opérationnelles dont un produit web classique peut se passer. La redondance des fournisseurs : au moins deux fournisseurs de modèles câblés via une fine couche d'abstraction, avec la capacité de basculer en quelques secondes. L'évaluation des sorties en production : une vérification automatisée par échantillonnage que le modèle produit toujours des sorties acceptables, avec des alertes lorsque la qualité dérive. Les coupe-circuits de coûts : des limites strictes qui restreignent ou désactivent les fonctionnalités d'IA lorsque la facture prend une direction que l'entreprise n'a pas approuvée. Et un retour arrière qui inclut le prompt : pas seulement le code, mais le prompt, l'index de récupération et la suite d'évaluation — tous versionnés ensemble.
Rien de tout cela n'est exotique. C'est l'équivalent, en discipline opérationnelle, du port de la ceinture de sécurité. Le coût de l'omission, c'est le genre d'incident qui devient un post-mortem que personne n'a envie d'écrire.
Trois choix par défaut qui décident si une équipe peut livrer sereinement
Ce sont les pratiques que nous installons à chaque mission. Elles ne sont pas négociables : les omettre produit les incidents que nous devons ensuite nettoyer.
Un seul pipeline, aucune étape manuelle
Chaque changement passe par le même pipeline : compilation, tests, vérification de sécurité, déploiement. Aucune étape manuelle ne dépend du portable, du compte ou de la mémoire d'un ingénieur en particulier.
Une observabilité détenue par l'équipe
Les tableaux de bord, les alertes et les runbooks sont détenus par l'équipe qui détient le code. L'observabilité n'est pas une fonction séparée ; elle fait partie du travail d'ingénierie.
Une garde humaine
Les rotations de garde sont dimensionnées pour qu'un ingénieur ne soit pas de garde plus d'une semaine sur cinq. Les alertes sont calibrées pour qu'un ingénieur de garde puisse dormir. Si le système ne peut pas le garantir, on corrige le système, pas la rotation.
Une équipe qui livre chaque jour et dort chaque nuit
La maturité opérationnelle se ressent comme de l'ennui — et l'ennui, dans cette discipline, est l'objectif.
Une couche opérationnelle mûre change le rythme de l'équipe d'ingénierie. Les déploiements ne sont plus des événements. Les incidents sont rares, contenus, et produisent de l'apprentissage plutôt que du traumatisme. L'ingénieur de garde passe une semaine sans être appelé. L'équipe livre constamment de petits changements, parce que les petits changements sont sûrs et les grands ne le sont pas.
Quand cela fonctionne, c'est invisible. Le test honnête, c'est ce que les ingénieurs disent de la rotation de garde. S'ils la décrivent comme humaine, la couche opérationnelle est saine. S'ils la décrivent autrement, il reste du travail à faire.
Lorsque SDEN termine une mission DevOps, le livrable n'est pas un manifeste Kubernetes. C'est une équipe capable de faire fonctionner le système sans nous, et qui en a envie.
DevOps et automatisation —
les questions qu'on nous pose.
Des réponses directes aux questions qu'on nous pose le plus souvent. Si la vôtre n'y est pas, écrivez à l'équipe.