Organisation, loi de Conway et intégration des Ops

Une fois la chaîne de valeur choisie et l'équipe de transformation lancée, vient la question décisive de l'organisation : comment structurer les équipes pour atteindre les objectifs de la chaîne de valeur. Car la manière dont nous organisons nos équipes détermine la manière dont le travail s'accomplit — et, par ricochet, l'architecture même du logiciel que nous produisons. Ce chapitre montre comment faire jouer la loi de Conway (Conway's Law) en notre faveur, puis comment intégrer l'exploitation (Ops) dans le travail quotidien du développement (Dev) sans recréer les silos que l'on cherche précisément à abattre.

La loi de Conway : l'organisation se grave dans le code

En 1968, le Dr Melvin Conway mène une expérience devenue célèbre. Une organisation de recherche sous contrat confie à huit personnes la fabrication de deux compilateurs, l'un pour le COBOL, l'autre pour l'ALGOL. Cinq personnes sont affectées au COBOL, trois à l'ALGOL. Résultat observé : le compilateur COBOL tournait en cinq phases, celui de l'ALGOL en trois. La structure du logiciel avait épousé la structure de l'équipe.

De cette observation naît la loi de Conway, selon laquelle « les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations… Plus une organisation est grande, moins elle a de souplesse, et plus le phénomène est prononcé ». Eric S. Raymond, auteur de The Cathedral and the Bazaar, en a forgé une version simplifiée et restée fameuse : « si vous avez quatre groupes qui travaillent sur un compilateur, vous obtiendrez un compilateur à quatre passes ».

Autrement dit, la façon dont nous organisons nos équipes a un effet puissant sur le logiciel que nous produisons, ainsi que sur ses caractéristiques architecturales et opérationnelles. Pour obtenir un flux rapide du travail de Dev vers Ops, avec une qualité élevée et de bons résultats clients, il faut organiser équipes et travail de telle sorte que la loi de Conway joue en notre faveur. Mal appliquée, elle empêche les équipes de travailler en sécurité et de façon indépendante : elles deviennent fortement couplées, s'attendent mutuellement, et le moindre changement peut produire des conséquences globales et catastrophiques.

Le cas Sprouter chez Etsy : une couche prédite par Conway

L'histoire de Sprouter, chez Etsy, illustre admirablement comment la loi de Conway peut entraver ou renforcer nos objectifs. Le parcours DevOps d'Etsy commence en 2009 ; l'entreprise deviendra l'une des organisations DevOps les plus admirées, avec près de 200 millions de dollars de revenus en 2014 et une introduction en bourse réussie en 2015.

Développé en 2007, Sprouter — contraction de stored procedure router (« routeur de procédures stockées ») — résidait entre l'application front-end en PHP et la base de données Postgres, centralisant l'accès aux données. Comme l'expliquait Ross Snyder, ingénieur senior chez Etsy, lors de sa présentation à Surge 2011 : « Sprouter était conçu pour permettre aux équipes Dev d'écrire du code PHP dans l'application, aux DBA d'écrire du SQL dans Postgres, Sprouter les aidant à se rejoindre au milieu. »

Le problème : tout changement de logique métier provoquait des frictions considérables. « Pour presque toute nouvelle fonctionnalité du site, Sprouter exigeait que les DBA écrivent une nouvelle procédure stockée », observe Snyder. Les développeurs dépendaient donc de l'équipe DBA, avec son cortège de priorisations, de coordinations, de files d'attente et de réunions. Pire, les procédures stockées étaient elles-mêmes fortement couplées à Sprouter : modifier l'une exigeait de modifier l'autre. Sprouter était devenu un point de défaillance unique toujours plus gros, au couplage si serré que presque chaque déploiement provoquait une mini-interruption de service.

Tout s'explique par la loi de Conway. Au départ, deux équipes (développeurs et DBA) étaient responsables de deux couches (logique applicative et procédures stockées). Deux équipes, deux couches — exactement ce que prédit la loi. Sprouter, censé simplifier la vie des deux, a en réalité ajouté une troisième couche : désormais, un changement de règle métier exigeait des modifications dans l'application, dans les procédures stockées et dans Sprouter. Trois couches, trois équipes à coordonner, des délais qui s'allongent et des problèmes de fiabilité.

La solution consista à remonter toute la logique métier de la base vers la couche applicative, rendant Sprouter inutile. Une petite équipe écrivit une couche de mapping objet-relationnel (object-relational mapping, ORM) en PHP, permettant aux développeurs front-end d'appeler directement la base et ramenant de trois à une le nombre d'équipes nécessaires pour modifier la logique métier. La migration prit deux ans ; Sprouter resta en production tout du long. En l'éliminant, Etsy supprima les coordinations inter-équipes, réduisit les transferts (handoffs), accéléra et fiabilisa nettement les déploiements, et — parce que de petites équipes pouvaient enfin développer et déployer sans dépendre des autres — augmenta la productivité des développeurs. Sprouter quitta la production et les dépôts de version début 2011. « Wow, ça faisait du bien », conclut Snyder.

Les trois archétypes organisationnels

Les sciences de la décision distinguent, selon le Dr Roberto Fernandez, trois grands types de structures qui orientent la conception de nos chaînes de valeur. Les saisir aide à comprendre où mènent nos choix.

Archétype	Optimise pour	Caractéristiques	Risque dominant
Fonctionnel (functional)	L'expertise, la division du travail, la réduction des coûts	Centralise l'expertise ; hiérarchies hautes ; spécialistes regroupés (DBA, réseau, serveurs…)	Silos, files d'attente, délais longs
Matriciel (matrix)	Combiner fonctionnel et marché	Souvent complexe ; un contributeur peut dépendre de deux managers ou plus	N'atteint ni l'un ni l'autre des deux buts
Orienté marché (market)	Répondre vite aux besoins clients	Plat ; équipes pluridisciplinaires et autonomes ; redondances possibles	Doublons à travers l'organisation

L'orientation fonctionnelle a longtemps prévalu pour l'exploitation : administrateurs serveurs, réseau, base de données regroupés en équipes distinctes. L'orientation marché, à l'opposé, est celle de nombreuses organisations DevOps de premier plan : chez Amazon ou Netflix, dans les cas extrêmes, chaque équipe de service est simultanément responsable de la livraison des fonctionnalités et du support de son service en production.

Les dangers d'une orientation trop fonctionnelle (« optimiser pour le coût »)

Quand on organise par spécialité — les DBA d'un côté, les administrateurs réseau de l'autre, les administrateurs serveurs ailleurs — la conséquence la plus visible est l'allongement des délais, particulièrement pour les activités complexes comme les grands déploiements, où il faut ouvrir des tickets auprès de plusieurs groupes et coordonner des transferts, le travail patientant dans de longues files à chaque étape.

S'y ajoute un mal plus insidieux : la personne qui exécute la tâche n'a souvent aucune visibilité sur le lien entre son travail et les objectifs de la chaîne de valeur (« je configure juste des serveurs parce qu'on me l'a demandé »). Le travailleur est placé dans un vide de créativité et de motivation. Le problème empire lorsque chaque domaine fonctionnel doit servir plusieurs chaînes de valeur qui se disputent ses cycles rares : il faut escalader vers un manager, un directeur, puis un dirigeant capable d'arbitrer selon les objectifs globaux plutôt que selon ceux du silo — décision qui redescend ensuite, modifie les priorités locales et ralentit les autres équipes. Quand chacun cherche à faire passer son travail en priorité, tous les projets finissent par avancer au même rythme d'escargot, avec leur lot de transferts ratés, de reprises, de problèmes de qualité, de goulots et de retards.

Activer des équipes orientées marché (« optimiser pour la vitesse »)

Pour obtenir des résultats DevOps, il faut donc réduire les effets de l'orientation fonctionnelle (« optimiser pour le coût ») et activer l'orientation marché (« optimiser pour la vitesse »), afin que de nombreuses petites équipes travaillent en sécurité et de façon indépendante. Poussées à l'extrême, les équipes orientées marché sont responsables non seulement du développement, mais aussi du test, de la sécurisation, du déploiement et du support de leur service en production, de l'idée jusqu'au retrait. Pluridisciplinaires et indépendantes, elles peuvent mener des expériences, livrer des fonctionnalités et corriger les défauts sans dépendances manuelles vers d'autres équipes. Amazon attribue à ce modèle sa capacité à rester rapide même en grandissant.

Surtout, on ne procède pas par une grande réorganisation descendante — source de perturbation, de peur et de paralysie. On embarque plutôt les ingénieurs fonctionnels (Ops, QA, sécurité) dans chaque équipe de service, ou l'on met leurs capacités à disposition via des plateformes automatisées en libre-service (self-service platforms) qui fournissent des environnements proches de la production, lancent des tests ou réalisent des déploiements.

Ce constat rejoint le « second paradoxe Toyota » : dans les années 1980, les chercheurs lean s'étonnaient que Toyota, modèle de l'amélioration continue, reste organisé de façon fonctionnelle. Mike Rother l'explique dans Toyota Kata : « On ne peut pas se réorganiser pour atteindre l'amélioration continue. Ce qui est décisif, ce n'est pas la forme de l'organisation, mais la manière dont les gens agissent et réagissent. » Les racines du succès tiennent au développement de capacités et d'habitudes chez les personnes.

La qualité, l'exploitation et la sécurité, l'affaire de tous, chaque jour

Dans les organisations performantes, qualité, disponibilité et sécurité ne sont pas la responsabilité de départements isolés : elles font partie du travail de chacun, chaque jour. Jody Mulkey, CTO de Ticketmaster, a renoncé à sa vieille métaphore footballistique opposant Ops (la défense) et Dev (l'attaque) : « Je me suis rendu compte qu'elle était fausse, car ils ne sont jamais sur le terrain en même temps. Ils ne sont pas dans la même équipe ! » Sa nouvelle analogie : « Ops, ce sont les joueurs de ligne offensive, et Dev les postes à compétence comme le quarterback ; le rôle d'Ops est de donner à Dev le temps d'exécuter ses actions. »

Un exemple frappant de douleur partagée renforçant les objectifs partagés : Facebook en 2009, en pleine croissance. Les déploiements posaient de gros problèmes, avec une lutte chronique contre les incendies. Pedro Canahuati, directeur de l'ingénierie de production, raconte une réunion où l'on demanda à toute personne ne travaillant pas sur un incident de fermer son ordinateur portable : personne ne le put. L'une des décisions les plus marquantes fut de faire tourner tous les ingénieurs, managers et architectes par l'astreinte (on-call) des services qu'ils construisaient. Chacun éprouva ainsi un retour viscéral sur ses décisions d'architecture et de code en amont, ce qui transforma les résultats en aval.

Faire de chacun un généraliste

Quand les départements se sur-spécialisent, ils se siloïsent — le Dr Spear parle de départements qui « se comportent comme des États souverains ». La moindre activité complexe exige alors transferts et files entre domaines de l'infrastructure. Une contre-mesure : encourager chaque membre à devenir généraliste, en lui offrant l'occasion d'apprendre toutes les compétences nécessaires pour construire et exploiter ses systèmes, et en faisant tourner les rôles. C'est l'idée du full-stack engineer — un généraliste familier de toute la pile, du code à la base, de l'OS au réseau et au cloud.

Scott Prugh raconte que CSG International a regroupé sur une même équipe la plupart des ressources nécessaires pour construire et exploiter le produit : analyse, architecture, développement, test et exploitation. « Par la formation croisée, des généralistes peuvent abattre un travail d'un ordre de grandeur supérieur à celui de leurs homologues spécialistes, et cela améliore le flux en supprimant files et temps d'attente. » Aux managers qui objectent « je peux embaucher deux administrateurs serveurs pour le prix d'un ingénieur Ops multi-compétences », il répond que les bénéfices d'un flux plus rapide écrasent le calcul, et que la formation croisée est « la bonne chose pour la carrière des employés ». Valoriser les gens pour leurs seules compétences actuelles entretient ce que le Dr Carol Dweck appelle l'état d'esprit fixe (fixed mindset) ; il faut au contraire cultiver l'état d'esprit de croissance (growth mindset). Jason Cox, directeur de l'ingénierie système chez Disney, résume sa nouvelle politique d'embauche : « Nous cherchions des gens dotés de curiosité, courage et candeur, capables d'être généralistes mais aussi renégats… Nous voulons promouvoir la disruption positive pour que notre métier ne reste pas coincé. »

Financer des services et des produits, pas des projets

Un autre levier consiste à créer des équipes de service stables, dotées d'un financement pérenne pour exécuter leur propre feuille de route. Cela tranche avec le modèle classique où l'on affecte Dev et Test à un « projet » avant de les réaffecter ailleurs dès le projet terminé : les développeurs ne voient jamais les conséquences à long terme de leurs décisions, et le financement ne paie que les premières étapes du cycle de vie — les moins coûteuses, justement. Comme le plaisante John Lauderbach, « chaque nouvelle application est comme un chiot offert : ce n'est pas le coût initial qui vous tue, c'est la maintenance et le support qui suivent ». L'objectif d'un financement par produit est de valoriser les résultats organisationnels et clients (revenus, valeur vie client, taux d'adoption) avec le minimum de production, plutôt que le respect d'un budget, d'un délai et d'un périmètre.

Concevoir les frontières d'équipe selon la loi de Conway

À mesure qu'une organisation grandit, le grand défi devient le maintien d'une communication et d'une coordination efficaces. Quand les équipes occupent des étages, des bâtiments ou des fuseaux horaires différents, la confiance mutuelle s'érode ; elle l'est plus encore lorsque le canal principal devient le ticket et la demande de changement, ou pire, lorsque des frontières contractuelles séparent les équipes (travail externalisé). Comme l'a montré Sprouter, découper les équipes par fonction (développeurs et testeurs séparés) ou par couche architecturale (application, base) engendre coordination lourde, reprises, désaccords de spécification, transferts ratés et attentes. L'architecture logicielle devrait au contraire permettre à de petites équipes d'être productives de façon indépendante, suffisamment découplées pour travailler sans communication ni coordination superflues.

Des architectures faiblement couplées

Dans une architecture fortement couplée (tightly-coupled), un petit changement peut provoquer des défaillances à grande échelle ; quiconque touche une partie du système doit sans cesse coordonner avec les autres, et tester l'ensemble exige d'intégrer les changements de centaines voire de milliers de développeurs dans de rares environnements d'intégration, longs à obtenir. D'où des délais en semaines ou en mois et une faible productivité.

À l'inverse, une architecture faiblement couplée (loosely-coupled) permet à de petites équipes d'implémenter, tester et déployer leur code de façon indépendante, sûre et rapide. Ces propriétés se retrouvent dans les architectures orientées services (service-oriented architectures, SOA), décrites dès les années 1990, où les services sont testables et déployables indépendamment. Un service faiblement couplé peut être mis à jour en production sans toucher aux autres ; il doit être découplé des autres services et des bases partagées (le partage d'un service de base de données reste possible, à condition de ne pas partager de schémas). La notion de contexte délimité (bounded context), tirée du Domain-Driven Design d'Eric Evans, complète l'idée : un développeur doit pouvoir comprendre et modifier un service sans rien savoir des internes de ses pairs, l'interaction passant strictement par des API. Randy Shoup, ancien directeur d'ingénierie de Google App Engine, l'observe : « Des organisations comme Google et Amazon, avec ce type d'architectures, ont une flexibilité et une scalabilité incroyables. Elles comptent des dizaines de milliers de développeurs, et de petites équipes y restent extraordinairement productives. »

Garder des équipes petites : la règle des « deux pizzas »

La loi de Conway nous pousse aussi à garder des équipes de petite taille. Lors de sa sortie du code monolithique en 2002, Amazon adopta la règle des deux pizzas : une équipe pas plus grande que ce que deux pizzas peuvent nourrir, soit cinq à dix personnes. Cette limite a quatre effets : elle garantit une compréhension partagée du système ; elle limite le rythme d'évolution du service ; elle décentralise le pouvoir et favorise l'autonomie (chaque two-pizza team définit avec la direction la métrique métier dont elle répond, sa fonction d'aptitude ou fitness function, qu'elle s'efforce ensuite de maximiser librement) ; enfin, mener une telle équipe offre une expérience de leadership à faible enjeu. Werner Vogels, CTO d'Amazon, le résumait : « Les petites équipes sont rapides… Chaque groupe assigné à un métier en est totalement responsable. L'équipe cadre le correctif, le conçoit, le construit, le déploie et surveille son usage. » Le lien entre la structure (la 2PT) et l'architecture (la SOA) était au cœur de la stratégie d'Amazon — Netflix érige d'ailleurs en valeur « fortement aligné, faiblement couplé » (highly aligned, loosely coupled).

Intégrer l'exploitation dans le quotidien du développement

Activer des résultats orientés marché est difficile quand l'exploitation reste centralisée et fonctionnelle, devant servir des équipes de développement aux besoins très divers. La solution n'est pas de disperser brutalement les Ops, mais de mieux intégrer leurs capacités aux équipes Dev. Chez Big Fish Games — des centaines de jeux mobiles et des milliers de jeux PC, plus de 266 millions de dollars de revenus en 2013 —, Paul Farrall, VP de l'exploitation, dirigeait une organisation centralisée au service d'unités très autonomes qui se disputaient un pool de ressources Ops rares. « Quand les équipes Dev avaient des problèmes de test ou de déploiement, il leur fallait plus que de la technologie : il leur fallait de l'aide et du coaching. Nous avons d'abord embarqué des ingénieurs Ops dans chaque équipe Dev, mais il n'y en avait pas assez. Nous avons pu aider davantage d'équipes, avec moins de personnes, grâce à un modèle de liaison Ops. » Farrall distinguait d'ailleurs deux types de liaisons. Le business relationship manager travaillait avec la gestion produit, les responsables de lignes métier, la direction du développement et les développeurs : intime des enjeux métier et des feuilles de route, il défendait les intérêts des product owners au sein de l'exploitation et aidait les équipes produit à naviguer dans le paysage Ops pour prioriser et fluidifier leurs demandes. Le dedicated release engineer, lui, connaissait par cœur les problèmes de développement et de QA du produit, exécutait souvent lui-même le travail Ops requis et, au besoin, mobilisait les ingénieurs Ops spécialisés (DBA, sécurité, stockage, réseau) tout en pesant sur les outils en libre-service que l'exploitation devait prioriser. Résultat : relations de travail avec l'Ops et vélocité des livraisons nettement améliorées, « sans ajouter d'effectifs ».

De cette expérience se dégagent trois grandes stratégies, à combiner selon les contraintes.

Pattern d'intégration Ops	Principe	Quand l'employer
Plateformes en libre-service (self-service)	Ops crée des plateformes et outils centralisés (environnements, pipelines, tests, télémétrie) utilisables à la demande	Toujours : socle qui augmente la productivité de toutes les équipes Dev
Ingénieurs Ops embarqués (embedded)	On place des ingénieurs Ops dans les équipes de service, dont ils épousent les priorités	Quand on a assez d'Ops et des projets d'envergure
Agents de liaison Ops (ops liaisons)	On désigne un référent Ops par équipe quand l'embarquement total est impossible	Coût ou rareté des Ops ; permet de couvrir plus d'équipes

Créer des services partagés en libre-service

Le premier pattern consiste à offrir des plateformes et outils centralisés que toute équipe Dev peut consommer : environnements proches de la production, pipelines de déploiement, outils de test automatisés, tableaux de bord de télémétrie. Idéalement, tout doit être automatisé et disponible à la demande, sans ouvrir de ticket ni attendre une action manuelle, faute de quoi l'exploitation redevient un goulot (« nous avons reçu votre demande, il faudra six semaines pour configurer ces environnements de test »). Comme l'observe Damon Edwards, « sans ces plateformes Ops en libre-service, le cloud n'est que de l'hébergement coûteux 2.0 ».

Point capital : on n'impose presque jamais ces plateformes. Les équipes plateformes doivent séduire leurs clients internes, parfois en concurrence avec des fournisseurs externes, et faire de leur offre le « chemin de moindre résistance ». Concevoir et maintenir ces plateformes est un vrai travail de développement produit, dont les clients sont les équipes Dev internes. Dianne Marsh, directrice des outils d'ingénierie chez Netflix, le formule nettement : « Nous construisons des outils pour permettre le libre-service. Il est acceptable que les gens dépendent de nos outils, mais il est important qu'ils ne dépendent pas de nous. » Ces plateformes intègrent l'expérience cumulée de QA, Ops et sécurité, facilitent la standardisation — un ingénieur reste productif même en changeant d'équipe — et se construisent de préférence en généralisant ce qui marche déjà quelque part, plutôt qu'en concevant tout pour la réutilisation a priori, mode d'échec coûteux et fréquent.

Embarquer des ingénieurs Ops dans les équipes de service

Le deuxième pattern rend les équipes produit plus autonomes en y embarquant des ingénieurs Ops, dont les priorités sont alors dictées par les objectifs de l'équipe — non par les problèmes internes de l'exploitation. L'équipe produit finance souvent le poste, même si l'embauche reste pilotée par l'Ops centralisée pour garantir la cohérence. Jason Cox, chez Disney, témoigne : « Nous avons embarqué des Ops dans les équipes produit de nos unités métier, ainsi que dans Dev, Test et même la sécurité. Cela a totalement changé notre façon de travailler. Dans l'Ops traditionnelle, nous conduisions simplement le train que d'autres avaient construit. Dans l'ingénierie d'exploitation moderne, nous aidons à construire le train et les ponts sur lesquels il roule. » L'ingénieur embarqué participe à tous les rituels Dev, influence l'architecture en amont, contribue aux plateformes internes ; à mesure que le besoin décroît, il peut migrer vers d'autres projets. Avantage majeur : l'appairage (pairing) Dev/Ops est un moyen extrêmement efficace de transférer le savoir d'exploitation dans l'équipe, et de le transformer en code automatisé, plus fiable et réutilisable.

Affecter un agent de liaison Ops

Faute de pouvoir embarquer des Ops partout, on désigne un agent de liaison par équipe — modèle baptisé designated Ops chez Etsy, où l'exploitation centralisée continue de gérer tous les environnements, y compris de pré-production, pour préserver leur cohérence. L'ingénieur de liaison doit comprendre la nouvelle fonctionnalité et sa raison d'être, son comportement en matière d'opérabilité, de scalabilité et d'observabilité (le diagramme est vivement encouragé), la façon de la surveiller, les écarts par rapport aux patterns antérieurs, les besoins d'infrastructure et les plans de lancement. Comme l'Ops embarqué, il assiste aux standups, intègre les besoins à la feuille de route Ops et escalade les conflits de ressources, qui sont alors arbitrés à l'aune des objectifs globaux. Ce modèle couvre plus d'équipes que l'embarquement ; mais si les liaisons sont trop étirées au point de devenir une contrainte, il faut réduire le nombre d'équipes par liaison, ou embarquer temporairement un ingénieur.

Intégrer les Ops aux rituels du Dev

Embarqués ou liaisons, les ingénieurs Ops gagnent à s'intégrer aux rituels des équipes Dev — sans que les méthodes agiles soient un prérequis : il s'agit de découvrir les rituels existants et d'y ajouter de la valeur. Comme le note Ernest Mueller, « DevOps marche bien mieux quand les équipes Ops adoptent les mêmes rituels agiles que les équipes Dev ».

• Mêlées quotidiennes (daily standups) : en y assistant, l'Ops prend conscience des activités à venir. Si un gros lancement est prévu dans deux semaines, on peut s'assurer que les bonnes ressources seront disponibles, ou repérer qu'il faut plus de supervision ou d'automatisation.
• Rétrospectives (retrospectives) : l'Ops y bénéficie des apprentissages et, après un déploiement, en présente les résultats — créant un retour vers l'équipe produit. Les feedbacks d'exploitation aident l'équipe à voir l'impact aval de ses décisions et révèlent souvent défauts et problèmes d'architecture. Le travail d'amélioration ainsi identifié (corrections, refactorisation, automatisation) ne doit pas être indéfiniment reporté au profit des fonctionnalités : l'amélioration du travail quotidien est plus importante que le travail quotidien lui-même, et toute équipe doit lui réserver une capacité dédiée (par exemple 20 % des cycles).
• Tableaux Kanban partagés (shared kanban boards) : rendre le travail Ops visible est essentiel. Trop souvent, les tableaux n'affichent pas le travail d'exploitation nécessaire pour faire tourner l'application en production — on n'en prend conscience qu'au moment où il devient une crise. Puisque l'exploitation fait partie de la chaîne de valeur, son travail pertinent doit figurer sur le tableau partagé, ce qui révèle blocages et points d'escalade. Bien menée, cette visibilité produit des résultats orientés marché, quelle que soit la façon dont sont dessinés nos organigrammes.

À retenir

• La loi de Conway établit que l'architecture d'un système reflète la structure de communication de l'organisation : il faut donc concevoir les équipes pour qu'elle joue en notre faveur, sans quoi le couplage organisationnel se grave dans le code (cas Sprouter chez Etsy : deux équipes, deux couches, puis une troisième couche parasite).
• Trois archétypes : fonctionnel (optimise le coût, produit silos et files d'attente), matriciel (rate souvent les deux buts) et orienté marché (optimise la vitesse, équipes autonomes et pluridisciplinaires comme chez Amazon ou Netflix).
• On vise l'orientation marché non par réorganisation descendante, mais en embarquant les compétences fonctionnelles et en offrant des plateformes en libre-service — l'orientation fonctionnelle restant viable en haute confiance (Etsy, Google, GitHub).
• Des architectures faiblement couplées (SOA, contextes délimités) et des équipes petites (règle des deux pizzas d'Amazon, fonction d'aptitude) permettent à de petites équipes de livrer indépendamment, en sécurité et vite.
• Intégrer l'Ops au Dev passe par trois patterns : plateformes en libre-service (socle universel), ingénieurs Ops embarqués (Disney), et agents de liaison quand l'embarquement est impossible (Big Fish Games, designated Ops d'Etsy).
• Intégrer l'Ops aux rituels Dev — standups, rétrospectives, tableaux Kanban partagés — et rendre le travail Ops visible produit des résultats orientés marché quels que soient les organigrammes.
• L'objectif final reste constant : que l'exploitation cesse d'être une contrainte pour les équipes produit, sans recréer de nouveaux silos.