Par où commencer : choisir et comprendre son value stream

Toute transformation commence par une question redoutable : par où débuter ? L'incertitude est totale — on trace une route vers un état idéal dont presque aucune étape intermédiaire n'est connue d'avance. Là où Accelerate établissait pourquoi la performance de livraison compte, The DevOps Handbook bascule dans le comment : il propose un processus de décision concret, des étapes actionnables et, surtout, des études de cas pour choisir la bonne chaîne de valeur (value stream) de départ, comprendre le travail qui s'y déroule réellement, et étendre méthodiquement l'initiative au reste de l'organisation. Comme l'observait Michael Rembetsy, directeur de l'exploitation chez Etsy au moment de la transformation de 2009 : « Quand on est en difficulté, on n'a pas droit à beaucoup d'essais. Il faut donc choisir avec soin — puis protéger — les projets d'amélioration qui amélioreront le plus l'état de notre organisation. »

Greenfield ou brownfield : le terrain de départ

On classe couramment ses services logiciels en deux familles, empruntées à l'urbanisme. Un projet terrain vierge (greenfield) se construit sur un sol jamais exploité : une initiative nouvelle, encore au stade de la conception, où l'on bâtit applications et infrastructure presque sans contrainte. Un projet friche industrielle (brownfield) se construit, lui, sur un terrain déjà utilisé — potentiellement pollué : un produit existant, en service depuis des années voire des décennies, lesté d'une dette technique (technical debt) souvent considérable (aucune automatisation des tests, plateformes non supportées).

Critère	Greenfield (terrain vierge)	Brownfield (friche industrielle)
Nature	Projet ou produit neuf, en phase de conception	Produit ou service existant, parfois vieux de décennies
Contraintes	Peu : ni code legacy, ni processus, ni équipe en place	Fortes : dette technique, architecture couplée, legacy
Usage typique	Pilote pour démontrer la faisabilité (cloud, automatisation)	Transformation d'un système critique, à fort enjeu métier
Exemple	Hosted LabVIEW chez National Instruments (2009)	Nordstrom, CSG, Etsy

L'intuition voudrait que DevOps soit d'abord affaire de greenfield. C'est une idée reçue. Chez National Instruments — organisation de trente ans, cinq mille employés, un milliard de dollars de revenu — une équipe restreinte (architectes applicatif et système, deux développeurs, un automaticien, un responsable d'exploitation et deux opérateurs offshore) fut autorisée à opérer hors des processus IT existants et à explorer les clouds publics : elle livra Hosted LabVIEW en deux fois moins de temps que les introductions de produits habituelles. Mais le constat le plus marquant tient ailleurs.

Que les services au plus fort potentiel métier soient des systèmes brownfield ne devrait pas surprendre : ce sont précisément ceux dont l'organisation dépend le plus, qui portent le plus de clients et le plus de revenu. Les équipes qui les soutiennent sont souvent très réceptives à l'expérimentation, surtout lorsqu'il existe la conviction partagée que les méthodes traditionnelles ne suffiront pas — et un sentiment d'urgence. CSG International en est l'illustration : en 2013, avec 747 millions de dollars de revenu et plus de 3 500 employés, l'entreprise s'attaqua d'abord à l'impression de factures, portée par une application COBOL sur mainframe et vingt plateformes périphériques. En déployant quotidiennement dans un environnement de type production, elle doubla la fréquence des livraisons (de deux à quatre par an) et fit fondre le délai de livraison (lead time) de deux semaines à moins d'une journée. Quant à Etsy (2009) — trente-cinq employés, 87 millions de dollars de revenu —, c'est après avoir « à peine survécu à la saison des fêtes » qu'elle transforma presque tout, pour devenir l'une des organisations DevOps les plus admirées et réussir son introduction en bourse en 2015.

Systèmes d'enregistrement et systèmes d'engagement : refuser le « bimodal IT »

Le cabinet Gartner a popularisé la notion d'IT bimodale (bimodal IT), qui sépare deux familles de systèmes. Les systèmes d'enregistrement (systems of record) — type ERP, MRP, RH, reporting financier — font tourner l'entreprise et exigent une exactitude absolue des transactions et des données ; ils connaissent un rythme de changement plus lent et portent souvent des exigences réglementaires et de conformité (par exemple SOX) — autant de raisons pour lesquelles Gartner les dit « de Type 1 », où l'on cherche à « bien faire les choses ». Les systèmes d'engagement (systems of engagement) — applications client ou collaborateur, e-commerce, productivité — connaissent un rythme de changement bien plus élevé pour soutenir des boucles de rétroaction rapides ; ce sont les « Type 2 », où l'on cherche à « faire vite ».

Diviser ainsi son patrimoine est commode, mais piégeux. Le conflit chronique entre « bien faire » et « faire vite » n'est pas une fatalité : DevOps le brise. Les données du State of DevOps montrent — dans la lignée du lean manufacturier — que les organisations très performantes atteignent simultanément un débit et une fiabilité supérieurs. Surtout, parce que nos systèmes sont profondément interdépendants, notre capacité à modifier n'importe lequel d'entre eux est limitée par celui qui est le plus difficile à changer en sécurité — et c'est presque toujours un système d'enregistrement.

En améliorant un système brownfield, on ne doit donc pas se contenter de réduire sa complexité et d'accroître sa fiabilité : il faut aussi le rendre plus rapide, plus sûr et plus facile à changer. Car même lorsqu'on ajoute des fonctionnalités à un seul système d'engagement greenfield, on provoque fréquemment des problèmes de fiabilité dans les systèmes d'enregistrement brownfield dont il dépend. Rendre ces systèmes aval plus sûrs à changer, c'est aider toute l'organisation à atteindre ses objectifs plus vite et plus sûrement.

L'exemple Nordstrom : choisir des terrains réceptifs

Fondé en 1901, Nordstrom est un distributeur de mode (13,5 milliards de dollars de revenu en 2015). Le déclencheur de sa transformation remonte à un conseil d'administration de 2011, où la croissance du revenu en ligne s'imposa comme sujet stratégique — les administrateurs avaient sous les yeux le sort de Blockbuster, Borders et Barnes & Noble, ces distributeurs traditionnels que leur retard sur l'e-commerce menaçait de disparition. Courtney Kissler, alors directrice de la livraison des systèmes, décrivit la situation : « En 2011, l'organisation technologique de Nordstrom était entièrement optimisée pour le coût — beaucoup de fonctions externalisées, un cycle de planification annuel avec de gros lots, des livraisons en cascade. Même avec un taux de réussite de 97 % sur le calendrier, le budget et le périmètre, nous étions mal équipés pour ce que la stratégie à cinq ans exigeait, dès lors que Nordstrom s'est mis à optimiser pour la vitesse plutôt que pour le seul coût. »

Plutôt que de bouleverser tout le système, l'équipe choisit trois domaines précis dont les objectifs métier n'étaient pas atteints — donc plus réceptifs à une autre façon de travailler : l'application mobile, les systèmes des restaurants Café Bistro en magasin, et les propriétés numériques. L'objectif : démontrer des victoires précoces qui donneraient à tous la confiance que ces améliorations sont reproductibles ailleurs.

L'application mobile, aux avis uniformément négatifs au lancement, ne pouvait être mise à jour que deux fois par an : tout correctif attendait des mois. Nordstrom créa une équipe produit dédiée, capable d'implémenter, tester et livrer de la valeur de façon autonome, sans dépendre de dizaines d'autres équipes ; on passa d'une planification annuelle à une planification continue, avec un backlog unique priorisé selon le besoin client. En un an, l'équipe supprima le test comme phase distincte pour l'intégrer au travail quotidien, doubla les fonctionnalités livrées par mois et divisa par deux les défauts.

Les systèmes des restaurants relevaient d'un besoin inverse : non pas accélérer la mise sur le marché, mais réduire les coûts et accroître la qualité. Après onze « re-concepts » de restaurant en 2013 — source de nombreux incidents clients — quarante-quatre étaient prévus pour 2014. « Un de nos dirigeants a suggéré de tripler l'équipe, raconte Kissler ; j'ai proposé d'arrêter de jeter des bras sur le problème et d'améliorer plutôt notre façon de travailler. » En ciblant la prise en charge du travail et le déploiement, l'équipe réduisit les délais de déploiement de 60 % et les incidents de production de 60 à 90 %. Forte de ces succès, Kissler fut promue VP, et lança en 2015 un mandat transversal : réduire de 20 % les temps de cycle de tous les services orientés client.

Étendre par la diffusion de l'innovation, jamais par décret

Dans toute organisation coexistent des attitudes très diverses face aux idées nouvelles. Geoffrey A. Moore, dans Crossing the Chasm, a popularisé le cycle de vie de l'adoption technologique (technology adoption life cycle), où un « gouffre » sépare les premiers convaincus de la majorité. Les innovateurs et adopteurs précoces (early adopters) embrassent vite les idées neuves ; la majorité précoce, la majorité tardive et les retardataires, plus conservateurs, y résistent. La stratégie est donc claire : trouver les équipes qui croient déjà au besoin de DevOps et savent innover sur leurs propres processus — et ne pas perdre son énergie, au début, à convaincre les groupes les plus réfractaires.

Pour étendre l'initiative, The DevOps Handbook reprend une séquence enseignée par le Dr Roberto Fernandez (MIT) que suivent les agents du changement pour bâtir et élargir leur coalition.

  Phase 1            Phase 2                    Phase 3
  ───────            ───────                    ───────
  Innovateurs   ──►  Masse critique &      ──►  Réfractaires
  & adopteurs        majorité silencieuse       (« holdouts »)
  précoces
  (volontaires,      (équipes réceptives,       (détracteurs
   respectés,         effet boule de neige ;     influents — on
   influents)         on évite les batailles      ne les affronte
                      politiques dangereuses)     qu'APRÈS la
                                                  majorité acquise)

On commence par les innovateurs et adopteurs précoces : les volontaires, idéalement respectés et influents, qui donnent de la crédibilité. On construit ensuite la masse critique et la majorité silencieuse, en travaillant avec des équipes réceptives même peu visibles, ce qui crée un effet d'entraînement (bandwagon) tout en contournant les batailles politiques risquées. On ne s'attaque aux réfractaires — détracteurs influents, susceptibles de saboter — qu'une fois la majorité silencieuse acquise et assez de succès accumulés pour protéger l'initiative. Comme le résume Ron van Kemenade, CIO d'ING : « Conduire le changement demande du courage, surtout en entreprise où les gens ont peur et vous combattent. Mais si vous commencez petit, vous n'avez vraiment rien à craindre. »

À chaque étape, il faut démontrer des victoires précoces et diffuser ses succès — en découpant les grands objectifs en petits pas incrémentaux. Cela accélère non seulement les améliorations, mais permet aussi de détecter tôt qu'on a choisi le mauvais value stream, pour revenir en arrière et réessayer en s'appuyant sur les nouveaux apprentissages.

Comprendre le travail : l'atelier de value stream mapping

Une fois le value stream choisi, il faut comprendre comment la valeur est réellement livrée au client : quel travail, par qui, et quelles étapes améliorer. Or dans un flux d'une certaine complexité, personne ne connaît la totalité du travail — il est réparti entre des équipes éloignées sur l'organigramme, géographiquement ou par leurs incitations. D'où l'outil le plus efficace pour commencer : un atelier réunissant toutes les parties prenantes pour une cartographie de la chaîne de valeur (value stream mapping).

L'illustration favorite de Courtney Kissler concerne la « Cosmetics Business Office », application COBOL sur mainframe qui permettait aux responsables de rayon d'enregistrer les vendeuses pour suivre les commissions. Depuis près d'une décennie, à chaque cycle de planification annuel, on débattait de la nécessité de sortir cette application du mainframe — sans jamais le faire. L'atelier réunit tous ceux qui livraient de la valeur aux clients internes : partenaires métier, équipe mainframe, services partagés. La découverte fut inattendue : le formulaire de « demande d'affectation de gamme produit » réclamait un numéro d'employé que les responsables n'avaient pas — ils le laissaient vide ou inscrivaient « je ne sais pas ». Pire, pour remplir le formulaire, ils devaient quitter la surface de vente pour un PC en arrière-boutique. Résultat : un temps perdu énorme, le travail rebondissant d'un service à l'autre. En supprimant simplement le champ « numéro d'employé » (récupéré plus tard en aval), l'équipe gagna quatre jours de traitement ; en remplaçant le PC par une application iPad utilisable sans quitter le rayon, le délai tomba à quelques secondes. « Avec ces améliorations, conclut Kissler, toutes les demandes de migration hors du mainframe ont disparu — et d'autres dirigeants sont venus nous voir avec leurs propres listes d'expériences. »

Identifier les membres clés du flux

Après avoir choisi l'application candidate, on identifie tous les membres de la chaîne de valeur qui doivent coopérer pour créer de la valeur. En général : le product owner (la voix du métier qui définit les prochaines fonctionnalités) ; le développement ; la QA (qui garantit l'existence des boucles de rétroaction) ; l'exploitation (Ops, qui maintient la production et veille aux niveaux de service) ; la sécurité (Infosec) ; les gestionnaires de release ; et un dirigeant technologique ou value stream manager, responsable dans la littérature lean de « garantir que la chaîne de valeur atteint ou dépasse les exigences du client et de l'organisation, de bout en bout ».

Cartographier pour voir le travail

La première passe ne consiste qu'en blocs de processus de haut niveau : même pour un flux complexe, un groupe produit en quelques heures un diagramme de cinq à quinze blocs. Chaque bloc porte trois métriques : le délai (lead time, l'horloge qui tourne pour l'élément de travail, attente comprise), le temps de traitement (process time, le travail effectif sans l'attente) et le %C/A (pourcentage complet et correct), mesuré par les consommateurs en aval de la sortie.

  VALUE STREAM MAP (simplifiée)

  [Product   ]   [Dév +    ]   [Build &   ]   [Déploiement]
  [Owner     ]──►[code en  ]──►[tests en  ]──►[en         ]──► VALEUR
  [demande / ]   [version  ]   [pré-prod  ]   [production ]    CLIENT
  [hypothèse ]   [control  ]   [          ]   [           ]

  LT = 2 j        LT = 5 j      LT = 10 j      LT = 3 j
  PT = 4 h        PT = 3 j      PT = 1 j       PT = 2 h
  %C/A = 60 %     %C/A = 90 %   %C/A = 75 %    %C/A = 95 %
        ▲              ▲              ▲
        │              │              │
   formulaire     retouches     attente d'un
   sans n° empl.  d'intégration env. correctement
   (rework)                     configuré (delay)

Les valeurs chiffrées du schéma ci-dessus (LT, PT, %C/A) sont purement illustratives : elles n'apparaissent pas telles quelles dans le livre, qui renvoie lui-même à une figure d'exemple (Lean Enterprise, fig. 10). Elles ne servent qu'à montrer la forme de la carte, pas à fournir des repères chiffrés.

On concentre l'investigation sur deux zones : là où le travail attend des semaines ou des mois (obtention d'environnements de type production, processus d'approbation des changements, revues de sécurité) et là où s'engendre une retouche (rework) importante. Une fois la métrique à améliorer identifiée — un %C/A trop bas ici, un délai trop long là —, on observe plus finement, puis on construit une carte d'état futur idéalisée (idealized design) servant de condition cible (target condition) à atteindre sous trois à douze mois. Le leadership définit cet état futur, puis guide l'équipe : formuler des hypothèses et des contre-mesures, mener des expériences, interpréter les résultats — et itérer.

Constituer une équipe de transformation dédiée

Toute transformation entre en conflit avec les opérations courantes. Une organisation longtemps prospère a érigé des mécanismes pour perpétuer ce qui l'a fait réussir : spécialisation, recherche d'efficacité et de répétabilité, bureaucraties d'approbation, contrôles contre la variance. Les bureaucraties sont d'une résilience redoutable — on peut en retirer la moitié, le processus survit. Excellent pour préserver le statu quo ; mais s'adapter au marché exige disruption et innovation, ce qui met l'initiative aux prises avec ceux qui tiennent les opérations quotidiennes, et qui gagnent presque toujours.

S'appuyant sur les travaux des Dr Vijay Govindarajan et Dr Chris Trimble (The Other Side of Innovation), le livre prescrit donc une équipe dédiée (dedicated team), distincte du moteur de performance (performance engine) qui assure le quotidien. Cette équipe est tenue responsable d'un résultat système, clairement défini et mesurable (par exemple : réduire de 50 % le délai de déploiement entre le commit en gestion de version et l'exécution réussie en production). Pour cela :

• affecter ses membres à 100 % à la transformation — surtout pas « gardez toutes vos responsabilités, mais consacrez 20 % de votre temps à ce nouveau truc DevOps » ;
• choisir des généralistes, dotés de compétences sur des domaines variés ;
• choisir des membres entretenant des relations de longue date et de respect mutuel avec le reste de l'organisation ;
• créer si possible un espace physique séparé, pour maximiser la communication interne et un certain isolement.

On affranchira l'équipe, autant que possible, des règles qui contraignent le reste de l'organisation — comme l'a fait National Instruments. Les processus établis sont une forme de mémoire institutionnelle : on a besoin que l'équipe dédiée en crée une nouvelle. Et créer cette équipe protège aussi le moteur de performance des perturbations liées à l'expérimentation.

S'accorder sur un objectif partagé, des horizons courts

On définit un objectif mesurable, daté (entre six mois et deux ans), exigeant mais atteignable, créateur de valeur évidente — accepté par les dirigeants et connu de tous. Quelques exemples : réduire de 50 % la part du budget consommée par le support et le travail non planifié ; garantir un délai du commit à la release en production d'une semaine ou moins pour 95 % des changements ; rendre possible des releases en heures ouvrées sans interruption de service ; intégrer tous les contrôles de sécurité requis dans le pipeline de déploiement. On limite aussi le nombre d'initiatives simultanées, pour ne pas saturer la capacité de conduite du changement.

Réserver 20 % des cycles à la dette technique

Le paradoxe de toute amélioration : les organisations qui en ont le plus besoin sont celles qui ont le moins de temps à y consacrer. C'est aigu en technologie, à cause de la dette technique. Une organisation qui ne rembourse jamais le principal de sa dette financière finit par ne plus pouvoir honorer ses intérêts ; de même, celle qui ne rembourse pas sa dette technique se retrouve si chargée de contournements quotidiens qu'elle ne peut plus produire de travail neuf — elle ne paie plus que les « intérêts » de sa dette.

La contre-mesure : investir au moins 20 % de tous les cycles de Dev et d'Ops dans le refactoring, l'automatisation, l'architecture et les exigences non fonctionnelles (non-functional requirements, NFR) — ces « -ilités » (maintenabilité, manœuvrabilité, scalabilité, fiabilité, testabilité, déployabilité, sécurité). Après la quasi-faillite d'eBay à la fin des années 1990, Marty Cagan (Inspired) a codifié la règle : « Le management produit prend 20 % de la capacité de l'équipe d'entrée de jeu et la confie à l'ingénierie pour qu'elle en fasse ce qu'elle juge nécessaire... Si vous êtes en très mauvaise posture, montez à 30 % ou plus. Mais je deviens nerveux quand des équipes croient pouvoir s'en tirer avec beaucoup moins de 20 %. » Sans ce « impôt de 20 % », la dette croît jusqu'à ce que les services deviennent si fragiles que la livraison de fonctionnalités s'arrête net — et le burnout s'installe.

L'illustration la plus spectaculaire est l'opération InVersion chez LinkedIn (2011). Six mois après son entrée en bourse, l'entreprise ploie sous des déploiements catastrophiques liés à Leo, son monolithe Java déployé une fois toutes les deux semaines, qui « tombait souvent en production ». Kevin Scott, VP Engineering arrivé trois mois avant l'IPO, prit une décision radicale : arrêter tout développement de fonctionnalités pendant deux mois pour refondre architecture, déploiements et environnements. « Vous entrez en bourse, le monde entier vous regarde, et vous annoncez au management que vous ne livrerez rien de neuf pendant deux mois. C'était effrayant. » Le résultat fut massif : LinkedIn se dota d'une chaîne d'outils complète, passa à trois mises à jour majeures par jour et, des 150 services de 2010, en exploitait plus de 750. « Votre rôle d'ingénieur, conclut Scott, c'est d'aider votre entreprise à gagner. » En trouvant et corrigeant les problèmes dans le travail quotidien, on évite précisément ces expériences de « mort imminente ».

Rendre le travail visible et partagé entre Dev et Ops

Pour savoir si l'on progresse, tout le monde doit connaître l'état courant du travail — avec une information à jour, sans cesse révisée pour s'assurer qu'elle éclaire la progression vers les conditions cibles. Comme l'observait Christopher Little : « Les anthropologues décrivent les outils comme des artefacts culturels. » En DevOps, on se sert des outils pour renforcer la culture et accélérer les changements de comportement souhaités.

L'objectif : que Dev et Ops partagent non seulement des objectifs, mais un backlog commun, stocké dans un système unique avec un vocabulaire partagé, afin de prioriser globalement. Plutôt que des silos séparés (Dev sous JIRA, Ops sous ServiceNow), on crée une file de travail commune : quand les incidents de production apparaissent dans le même système que le travail de développement, il devient évident — surtout avec un tableau kanban — qu'un incident en cours doit interrompre le reste. Le backlog unifié permet à chacun de prioriser depuis une perspective globale ; la dette technique identifiée mais non traitable immédiatement y est ajoutée, et l'on pioche dans le « temps des 20 % » pour solder les éléments du haut de la pile. Les salles de discussion (chat) — Slack, IRC et consorts — accélèrent encore le partage d'information, avec un historique automatiquement consigné, exploitable lors des post-mortems. Reste un revers, signalé par Ryan Martens (Rally Software) : l'attente d'une réponse immédiate peut générer un flot d'interruptions ; certaines demandes gagnent à passer par des outils plus structurés et asynchrones.

À retenir

• Le choix du value stream de départ dicte la difficulté de la transformation, ses participants et l'organisation des équipes : il mérite un examen soigneux et la protection des projets choisis (Rembetsy, Etsy).
• DevOps n'est pas réservé au greenfield : plus de 60 % des récits du DevOps Enterprise Summit 2014 étaient brownfield, et l'âge de l'application ne prédit pas la performance — seule compte son architecture pour la testabilité et la déployabilité.
• Refuser le piège du bimodal IT : systèmes d'enregistrement et d'engagement méritent vitesse et qualité ; le système le plus dur à changer en sécurité bride toute l'organisation, il faut donc le rendre plus sûr à changer.
• Étendre par la diffusion de l'innovation, jamais par décret : commencer par les innovateurs et adopteurs précoces, bâtir une masse critique, n'affronter les réfractaires qu'ensuite — en multipliant les victoires précoces et incrémentales.
• Comprendre avant d'agir via un atelier de value stream mapping : cinq à quinze blocs portant délai, temps de traitement et %C/A, pour cibler attentes et retouches, puis viser une carte d'état futur idéalisée (target condition à 3-12 mois).
• Une équipe de transformation dédiée, affectée à 100 %, composée de généralistes respectés, isolée du moteur de performance, tenue à un résultat système mesurable, avec des horizons de planification courts (itérations de 2 à 4 semaines).
• Réserver au moins 20 % des cycles au remboursement de la dette technique et aux exigences non fonctionnelles, et rendre le travail visible dans un backlog et un tableau communs à Dev et Ops (Nordstrom, LinkedIn).