Pourquoi le DevOps

Une équipe de développement livre une version. L'équipe d'exploitation la refuse : elle n'a pas été prévenue, la configuration diffère, et la mise en production tombe un jeudi soir. Les développeurs répondent que « ça marche sur nos machines ». L'exploitation répond que sa mission est la stabilité, et que chaque livraison est un risque.

Les deux ont raison, et c'est le problème. On les a payés pour des objectifs contradictoires : livrer vite d'un côté, ne rien casser de l'autre. Le résultat est prévisible — des livraisons rares, grosses, redoutées, et d'autant plus risquées qu'elles sont rares.

Le DevOps n'est pas un outil, ni un métier, ni un logiciel qu'on installe. C'est une réponse à cette contradiction d'organisation, et tout le reste du semestre en découle.

Le mur, et ce qu'il produit

Le cycle traditionnel enchaîne des phases séparées par des remises de travail.

1développement ──► recette ──► exploitation ──► production2     3 mois        3 semaines     1 semaine        ?

Quatre conséquences, et elles s'aggravent mutuellement.

Les lots grossissent. Puisque livrer coûte cher, on livre rarement, donc chaque livraison contient trois mois de modifications. Une version qui change deux cents fichiers est impossible à relire, impossible à tester exhaustivement, et impossible à diagnostiquer quand elle échoue.

Le risque augmente avec la taille du lot. C'est le point contre-intuitif du chapitre : on livre rarement pour réduire le risque, et c'est précisément ce qui l'augmente. Quand quelque chose casse dans un lot de deux cents modifications, on ignore laquelle est en cause.

Le retour arrière devient impossible. Revenir à la version précédente, c'est annuler trois mois de travail — donc on ne le fait pas, et l'on répare en urgence en production.

L'apprentissage s'arrête. Une équipe qui livre quatre fois par an n'a que quatre occasions annuelles d'apprendre de ses erreurs. Une qui livre tous les jours en a deux cent cinquante.

Les trois voies

Le mouvement s'énonce classiquement en trois principes, et ils forment le plan du semestre.

Le flux. Optimiser le trajet complet, du commit à la production, et non chaque étape isolément. Une équipe de développement deux fois plus rapide ne sert à rien si la mise en production prend trois semaines : le goulot d'étranglement décide du tout — c'est la loi d'Amdahl du chapitre 8 d'architecture, appliquée à une organisation. Rendre le flux visible, réduire la taille des lots, automatiser ce qui est répété : c'est l'objet des blocs II à V.

La rétroaction. Raccourcir la boucle entre une erreur et sa détection. Un bogue trouvé à l'écriture coûte une minute ; trouvé en recette, une heure ; trouvé en production, une journée et un incident. Tests automatisés, pipeline, supervision : tout le cours consiste à déplacer la détection vers la gauche.

L'apprentissage continu. Faire de chaque incident une source d'amélioration plutôt que de sanction. C'est la partie culturelle, et c'est la plus difficile à installer — voir la dernière section.

Mesurer : les quatre indicateurs DORA

Un programme d'amélioration qui ne se mesure pas est une opinion. Le programme de recherche DevOps Research and Assessment a dégagé quatre indicateurs qui, ensemble, prédisent la performance d'une équipe — et ils ont l'avantage d'être difficiles à truquer.

Les deux premiers indicateurs mesurent la vitesse, les deux derniers la stabilité. Le résultat central de ces travaux est contre-intuitif et vaut d'être retenu : les deux vont ensemble. Les équipes qui livrent le plus souvent sont aussi celles qui cassent le moins et réparent le plus vite. Le compromis supposé entre vitesse et stabilité n'existe pas — c'est l'accumulation de gros lots rares qui produit à la fois la lenteur et l'instabilité.

Deux mises en garde d'usage. Ces indicateurs mesurent une équipe et un système, jamais une personne — les employer pour évaluer quelqu'un les rend immédiatement inutiles. Et ils se prennent ensemble : améliorer la fréquence de déploiement en négligeant le taux d'échec ne fait que déplacer le problème.

Le post-mortem sans blâme

Un incident survient. Deux réactions possibles, et elles produisent des organisations opposées.

Chercher le responsable. Quelqu'un a fait une manipulation malheureuse, on le sait, on le dit. Le résultat est mécanique : la prochaine fois, personne ne signalera l'erreur, chacun retardera les livraisons risquées, et l'information cessera de circuler. L'organisation devient plus lente et moins sûre.

Chercher ce qui a rendu l'erreur possible. Pourquoi une commande manuelle pouvait-elle détruire la base ? Pourquoi n'y avait-il pas de confirmation, de sauvegarde testée, de séparation entre les environnements ? Ce sont des questions sur le système, et elles ont des réponses actionnables.

Le principe s'énonce ainsi : on suppose que chacun a agi au mieux compte tenu de ce qu'il savait à ce moment-là. L'erreur humaine n'est pas une explication, c'est un point de départ — elle demande pourquoi le système a permis, voire favorisé, cette erreur.

Un post-mortem tient en cinq parties : ce qui s'est passé, quand, quel a été l'impact mesuré, pourquoi cela a été possible, et quelles actions concrètes sont décidées avec un responsable et une échéance. Sans la dernière partie, c'est un rapport ; avec elle, c'est un apprentissage.

À vous

L'exercice calcule les quatre indicateurs à partir d'un journal de déploiements — dates, succès ou échec, heure de commit, heure de rétablissement — pour deux équipes fictives.

Vous verrez d'abord ce que chaque indicateur mesure réellement, puis vous éprouverez le résultat central : en faisant varier la taille des lots dans le simulateur fourni, vous obtiendrez mécaniquement l'un ou l'autre profil. Une même équipe, un même rythme de travail, et deux positions opposées dans le classement — parce que la seule chose qu'on a changée est la fréquence de livraison.

La dernière partie est un piège de mesure : une équipe qui améliore sa fréquence de déploiement en dégradant son taux d'échec n'a pas progressé, et l'exercice le rend visible.

// ── Un journal de déploiements ────────────────────────────────────────────
// heure en heures depuis le début de l'observation (720 h = un mois).
const JOURNAL_A = [
  { t: 2,   commit: 1,   ok: true },
  { t: 6,   commit: 5,   ok: true },
  { t: 9,   commit: 8.5, ok: false, retabli: 9.7 },
  { t: 14,  commit: 13,  ok: true },
  { t: 20,  commit: 19,  ok: true },
  { t: 26,  commit: 25,  ok: true },
  { t: 31,  commit: 30,  ok: true },
  { t: 38,  commit: 37,  ok: true },
];
const JOURNAL_B = [
  { t: 200, commit: 20,  ok: false, retabli: 380 },
  { t: 500, commit: 260, ok: true },
  { t: 700, commit: 520, ok: false, retabli: 900 },
];

function indicateurs(journal, dureeObservation) {
  const n = journal.length;
  const echecs = journal.filter((d) => !d.ok);
  return {
    frequence: 0,        // ← à écrire : déploiements par semaine
    delai: 0,            // ← à écrire : moyenne de (t − commit), en heures
    tauxEchec: 0,        // ← à écrire : part des déploiements ayant échoué
    retablissement: 0,   // ← à écrire : moyenne de (retabli − t) sur les échecs
  };
}

function classer(i) {
  const note = (v, seuils) => seuils.findIndex((s) => v <= s);
  return "à écrire";     // ← élite / haute / moyenne / faible
}

// ── Simuler l'effet de la TAILLE DES LOTS ─────────────────────────────────
// Une même équipe, un même rythme de travail : 240 modifications par mois.
// Seule varie la fréquence de livraison.
function simuler(modificationsParMois, deploiementsParMois) {
  const parLot = modificationsParMois / deploiementsParMois;
  // Hypothèse empirique : la probabilité qu'un lot casse croît avec sa
  // taille, et le temps de diagnostic aussi — on ne sait pas quelle
  // modification est en cause parmi celles du lot.
  const probaEchec = Math.min(0.9, 1 - Math.pow(0.995, parLot));
  const diagnostic = 0.5 + parLot * 0.15;   // heures
  return { parLot, probaEchec, diagnostic };
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez indicateurs() et classer(), puis comparez les deux équipes.
// 2. Faites varier deploiementsParMois de 1 à 240 : que deviennent le taux
//    d'échec et le temps de rétablissement ?
// 3. Une équipe passe de 4 à 30 déploiements par mois mais son taux d'échec
//    monte de 10 % à 45 %. A-t-elle progressé ?

console.log(JSON.stringify(indicateurs(JOURNAL_A, 720)));

En travaux pratiques

Le fil rouge du semestre est une petite application web de suivi de tickets — tickets — qu'on empaquettera, testera, déploiera, orchestrera et supervisera. Cette première séance ne touche pas encore au code : elle installe le vocabulaire de mesure sur lequel tout le reste s'appuiera.

Ce que la suite en fait

Le chapitre 2 remet à niveau les outils que tout le reste suppose — la ligne de commande, le réseau, et surtout Git, dont la stratégie de branchement décide directement de la taille des lots dont ce chapitre vient de parler.

Les blocs II à V construisent ensuite le flux, dans l'ordre où une modification le parcourt : empaquetée, vérifiée, livrée, déployée sur une infrastructure décrite, orchestrée. Et le bloc VI y ajoute ce sans quoi rien n'est mesurable — c'est là que les indicateurs de ce chapitre cessent d'être un tableau pour devenir un graphique qu'on regarde.

À retenir