Category Archives for "Fiche Pratique"

Processus d'élaboration de la stratégie de la tribu

Introduction au leadership tribal

Motiver une ou plusieurs équipes a toujours été un challenge pour un manager ou leader. Un challenge d’autant plus grand avec les nouvelles générations qui exigent – à juste titre – davantage du sens. Plus question d’exécuter une tâche – en particulier répétitive – sans savoir pourquoi. Plus question d’avoir le sentiment de n’être que l’engrenage d’une « machine », sans latitude pour exprimer sa créativité.

Dans cet article, nous ne traitons pas de management au sens strict (gérer un budget, un planning, un client, des « ressources humaines », etc) mais de leadership.

Le fruit d’une étude

Le Leadership Tribal nous vient d’une étude menée pendant plus de 10 ans sur plusieurs entreprises diverses. Entreprises américaines seulement mais nous allons voir que ce détail a peu d’importance car les principes qui en résultent sont universels. Cette étude ne s’intéresse pas à la dimension psychologique, sociologique (origine des personnes observées, culture, etc), ni même environnementale. Elle se focalise plutôt sur l’observation et l’analyse du langage, comportement et type de relation adopté. Elle part d’un principe simple : les mots qu’on utilise influencent notre comportement. Par exemple, face à une difficulté, se répéter à soi même « je ne vais pas y arriver » augmente nos chances de ne pas y arriver. Et c’est également valable à l’échelle d’un groupe de personnes (d’une tribu).

Qu’est ce qu’une tribu ?

Une tribu est un groupe de 20 à 150 personnes qui se connaissent suffisamment pour se saluer lorsqu’elles se croisent dans la rue. Une petite entreprise est une tribu, une grosse entreprise est une tribu de tribus.

5 stades, 5 discours

Cette étude a permis d’identifier 5 stades. A chaque stade est associée une façon de parler, un comportement et un type de relation.

Stade Discours Comportement Type de relation Population concernée
1 « La vie est nulle » Sabotage Exclu 2%
2 « Ma vie est nulle » Victime passive Isolée 25%
3 « Je suis génial (et pas toi) » Guerrier solitaire Domination personnelle 49%
4 « Nous sommes géniaux (et pas les autres) » Fierté tribale Partenariat stable 22%
5 « La vie est géniale » Émerveillement innocent Equipe Moins de 2%
Tableau de synthèse des 5 stades de tribu.

Leviers d’évolution

Ce paragraphe résume brièvement les principaux leviers permettant de passer d’un stade à un autre. Chaque stade s’appuyant sur les acquis du précédent, on ne peut « sauter » un stade. Pour vérifier si une personne ou tribu a atteint un nouveau stade, il suffit d’observer le langage, comportement et type de relation adoptés.

Stade 1 vers stade 2

Pour faire passer une personne du stade 1 (exclue et dont le discours est « la vie est nulle ») au stade suivant, on l’encourage à aller là ou l’action se déroule. Par exemple en déjeunant avec ses collègues, en participant aux réunions, etc. Par ailleurs, elle devra rompre ses liens avec les autres personnes du type « la vie est nulle ». On lui montrera également que la vie « fonctionne » pour d’autres et qu’elle aussi (la personne qu’on accompagne) peut donc avoir sa chance.

Stade 2 vers stade 3

Le discours des personnes de stade 2 tourne autour du thème « ma vie est nulle » et sont généralement isolées. Leur niveau d’implication est minimal et le signe d’un tel état d’esprit est souvent la présence d’affiches de « Dilbert » dans les locaux. Elles savent cependant que la vie peut réussir à d’autres.

Pour l’aider à évoluer vers le stade 3, on peut notamment :

  • L’encourager à créer des relations dyadiques (2 personnes), en particulier avec des personnes de « stade 3 avancé » qui ne demandent qu’à remplir un rôle de mentor et façonner des « mini-elle ».
  • Souligner ses compétences, ses forces et son potentiel à développer.
  • Lui proposer des projets qu’elle peut réussir à court terme et qui nécessitent peu de suivi ou surveillance.

Stade 3 vers stade 4

Une personne au stade 3 a pris confiance en ses capacités a travers plusieurs victoires et adopte un discours du type « je suis génial » avec pour sous-entendu « et pas toi ». Ses relations sont dyadiques afin de cloisonner. Il maîtrise ainsi la connaissance et les informations dont il dispose, qui constituent son « pouvoir ».

Pour l’aider à évoluer, on peut :

  • L’encourager à former des relations tryadiques (3 personnes) autour de valeurs fondamentales communes.
  • A travailler sur des projets dont le succès nécessite du partenariat et l’aider à prendre conscience à l’issue de ce projet que ce dernier n’aurait pas pu réussir sans l’aide des autres membres de l’équipe.
  • Lui montrer que le vrai pouvoir ne provient pas de la connaissance et la détention d’informations mais des réseaux.
  • L’encourager à user de transparence en communiquant à outrance plutôt qu’en communiquant uniquement les informations dont les autres ont besoin (stade 3).

L’épiphanie

La plupart des personnes interrogées dans le cadre de cette étude se positionnent généralement à 1 ou 2 stades au dessus de la réalité. La prise de conscience de l’existence de ces stades et de leur caractéristiques (langage, type de relation et comportement) aident à ouvrir peu à peu (ou brutalement) les yeux sur soi. L’aboutissement de cette phase d’introspection; cette « révélation » qui changera définitivement sa façon de parler, de se comporter et d’établir ses relations; est appelée « épiphanie ».

Stade 4 vers stade 5

Le stade 4 consiste à ne plus raisonner selon le « je » mais selon le « nous ». Le passage au stade 5 consiste à aller plus loin, à déplacer les montagnes, à « écrire l’histoire » en accomplissant des exploits qui n’avaient encore jamais été atteints au sein de l’entreprise ou au delà.

Processus d’élaboration de la stratégie de la tribu

Pour cela on met en place la « stratégie de la tribu » autour de valeurs fondamentales et une noble cause. Cette stratégie doit émerger de la tribu dans son ensemble et du contexte (économique, technologique, etc) plutôt que de la vision seule du leader. La définition de cette stratégie se fait en 4 temps :

  1. Identifier les valeurs fondamentales et la noble cause de la tribu qui fédérera les membres.
  2. Définir les résultats concrets visés (et non pas un objectif du genre « devenir numéro 1 mondial »).
  3. Faire l’inventaire des actifs de la tribu (atouts, compétences, ressources, etc) et vérifier que ces actifs permettent d’atteindre les résultats visés.
  4. Recenser les comportements à adopter pour atteindre les résultats visés et vérifier que les actifs permettent d’accomplir ces comportements.

Si les vérifications mentionnées révèlent des limites (pas assez d’actifs pour atteindre les résultats visés, ou comportements inappropriés), on révise les résultats ou définit des résultats intermédiaires et on ajuste les comportements.

Le leader devra toujours respecter les valeurs identifiées et la noble cause quitte à faire des renoncements (renoncer à un marché par exemple). Dans le cas contraire, la confiance est rompue, les valeurs et noble causes bafouées et plus rien n’a de sens. On régresse alors vers les stades inférieurs.

Changer d’huile régulièrement

Régulièrement, tous les 2 ou 3 mois par exemple, la tribu se réunit et prends le temps de faire le point. Elle fait l’inventaire de ce qui fonctionne et qu’il faut cultiver, de ce qui fonctionne moins bien et identifie les améliorations à apporter. Au besoin elle ajuste sa stratégie.

Notre société cultive le stade 3

Un livre de stade 3 parmi tant d’autres.

C’est triste à dire mais notre société – à travers notamment son système éducatif, le milieu du travail et les médias – cultive des personnalités de stade 3. Dès les bancs de l’école, les « bon points » nous poussent à l’individualisme et à la compétition, à conserver l’information qui permettra d’obtenir ce bon point (plutôt que de la partager pour aider les autres à progresser), à se comparer aux autres. La sonnerie nous dit quand nous devons changer de classe, faire une pause ou finir sa journée. De quoi nous préparer au monde du travail (surtout en usine). Les bons points cèdent ensuite la place aux notes, aux classements, etc. Puis la compétition au sein des grandes écoles prend le relais avec le bizutage illustrant l’état d’esprit suivant : « dans la vie, il faut en baver et c’est chacun pour soi. Ne fait confiance à personne. ».

Une fois dans le monde du travail, la culture « stade 3 » se poursuit avec à minima les évaluations et notes annuelles, les primes. Mais le pire concerne le secteur commercial au sein duquel la loi de la jungle atteint son paroxysme.

Le monde de l’édition quant à lui n’est pas en reste d’ouvrages de stade 3 prônant la compétition, l’individualisme et le dépassement des autres.

Aujourd’hui, des voix s’élèvent pour revoir notre système éducatif. Proposent un système au sein duquel les enfants ne sont pas infantilisés mais responsabilisés, écoutés et auto-disciplinés. Un système plus démocratique faisant participer les élèves aux décisions qui définissent le programme et la vie de l’établissement scolaire. La pédagogie est révisée pour enseigner selon des principes de coopération plutôt que de compétition. Un système dont le programme s’adapte aux passions de l’enfant sans juger que l’étude de l’anatomie d’une grenouille est plus importante que la construction d’un cerf volant. Un système au sein duquel l’enfant qui a compris un enseignement peut transmettre ce dernier avec ses propres mots aux autres élèves qui parlent le même langage (en complément de l’enseignant).

Bénéfices à partir du stade 4

Voici la liste des principaux bénéfices constatés sur les tribus de stade 4 :

  • Meilleure collaboration (autour de la noble cause).
  • Moins de peur et de stress grâce à l’absence de friction avec les autres (absence de compétition).
  • Basculement de la résistance au leadership vers son suivi par l’ensemble de la tribu.
  • Turn-over limité et conservation des talents.
  • Davantage d’engagement des membres de la tribu.
  • Formation sans effort grâce à l’enseignement apporté par la tribu à ses membres sur les dernières réflexions et pratiques.
  • Meilleurs indicateurs de santé : moins de blessure et d’arrêts maladie.
  • Meilleure compétitivité : créativité, connaissances, aspirations libérées.
  • Épanouissement des membres de la tribu (fun).

Conclusion

En guise de conclusion, voici un extrait du livre « Tribal Leadership » de Dave Logan, John King et Halee Fischer-Wright:

Alors que les leaders tribaux travaillent pour le bien du groupe, non pas pour eux même, ils sont récompensés par la loyauté, le travail acharné, l’innovation et la collaboration. La tribu produit un travail de la plus grande qualité en moins de temps. […] L’avenir de l’entreprise est le stade 5.

Pour aller plus loin

La vidéo de la session d’introduction au Tribal leadership tournée au Scrum Day 2013 (en français – 45′) :

Ci dessous, le support de présentation. Il est libre de droit, et peut par conséquent être utilisé, copié, projeté dans votre organisation sans compte à rendre à personne en dehors de me citer en tant qu’auteur.

Livraison Continue

Cet article décrit les principes et pratiques associés au Continous Delivery qui permettent d’appliquer concrètement le premier principe Agile : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ». Pour éviter toute confusion, précisons qu’il ne traite pas du processus de réalisation (Scrum ou Kanban par exemple) mais du processus de « déploiement » convertissant le code source produit par une ou plusieurs équipes de développement en une application utilisable en production. L’essentiel des notions abordées sont issues du livre Continuous Delivery de Jez Humble et David Farley.

Enjeux

L’objectif premier est la satisfaction du client. Cette satisfaction s’obtient en offrant bien sûr un logiciel qui répond aux attentes des utilisateurs en termes de fonctionnalités, ergonomie, performance et robustesse. Mais elle s’obtient également en réduisant autant que possible le délais entre l’idée (ou la demande) et la mise à disposition de la nouvelle fonctionnalité (ou évolution ou correctif) associée.

En complément des processus de réalisation Agile (Scrum ou Kanban par exemple), les principes et pratiques abordés dans cet article rendent possible l’adoption d’un rythme de livraison aux utilisateurs en production fréquent et rapide. Un rythme hebdomadaire par exemple avec une durée de livraison de quelques seconde à moins de 2 heures y compris dans des contextes complexes. Comme le vivent déjà certaines entreprises.

Principes

Tout repose sur 2 principes fondamentaux :

  • Automatiser la livraison avec pour objectif la mise au point d’une procédure « pousse bouton » permettant de rendre le processus de déploiement fiable et répétable (sans risque d’erreur humaine).
  • Livrer fréquemment afin d’éprouver, fiabiliser la procédure, mais surtout nous donner un feedback au plus tôt afin de réduire autant que possible les coûts d’ajustement et par la même occasion la frustration (aussi bien celle des développeurs obligés de retravailler leur code alors qu’ils sont déjà passés à autre chose et les utilisateurs obligés de patienter trop longtemps).

Le pipeline de déploiement

Livraison Continue ou Continuous Delivery - Pipeline de déploiement de base

Pipeline de déploiement de base. Source : Livre « Continuous Delivery » de Jez Humble et David Farley.

Le circuit que parcourent les changements apportés au code à partir du commit du développeur jusqu’à sa livraison en production est appelé le « pipeline de déploiement ».

Le schéma ci contre illustre les principales étapes d’un pipeline de base (dont certaines sont parallélisables). On peut voir ce dernier comme une extension de l’Intégration Continue.

 

Pour l’anecdote, le choix du terme « Pipeline » n’est pas inspiré des canalisations de type oléoduc mais du fonctionnement des microprocesseurs.

Pratiques

Les pratiques suivantes permettent d’appliquer concrètement les principes évoqués plus haut.

Builder ses binaires une seule fois

Des changements ou erreurs humaines peuvent s’inviter entre différents build portant sur une même version du code source. Un changement de paramètre de compilation ou une erreur de tag par exemple. Changements qui peuvent rendre l’investigation difficile en cas de problème. C’est pourquoi, une fois que les binaires générés sont réputés fonctionner sur le premier environnement, ce sont eux qu’on utilisera sur les suivants. Par la même occasion, le délais de build est autant de temps de gagné pour les autres étapes du pipeline (ce qui est fait n’est plus à faire).

Même procédure pour chaque environnement

Afin d’utiliser et donc tester des centaines de fois la procédure de déploiement et ainsi la fiabiliser, nous avons intérêt à faire en sorte que ce soit la même pour l’ensemble des environnements. Ce qui va nous obliger – pour notre plus grand bien – à externaliser toutes les variables d’environnement. Ces dernières trouveront généralement leur place dans un fichier de configuration type « properties » qui lui même trouvera sa place dans le gestionnaire de version (ce qui permettra de faciliter les investigations en cas de problème).

Tests de fumée sur les déploiements

Livrer en production ou autre environnement à enjeu n’est pas suffisant. Nous devons aussi vérifier que le tout fonctionne. Les tests de fumée remplissent ce rôle. Connexion à la page d’accueil de l’application web, vérification de la disponibilité de la base de données, ping du web-service d’une application tierce, etc.

Déployer sur une copie de la production

L’un des pièges courant concernant les problèmes de mise en production est celui issu des différences entre les environnements du projet. Différence de compilateur, de version d’OS (voire pire d’OS tout court), de stack, de patchs de l’OS, de système de répartition de charge, de configuration réseau (ex : emplacement par rapport au proxy), etc.

Nous avons tout intérêt à uniformiser tous les environnements et suivre avec rigueur le moindre changement apporté. Le recours à des serveurs virtuels peut faciliter les choses et accélérer au passage le délais de mise en disposition des environnements.

Chaque changement se propage sur tout le pipeline

Livraison Continue ou Continuous Delivery - Mouvement des changements

Mouvement des changements au sein du pipeline de déploiement. Source : livre « Continuous Delivery » de Jez Humble et David Farley

Chaque commit est candidat à traverser les étapes du pipeline. Le diagramme ci contre décrit le mouvement d’un changement de code à travers le pipeline de déploiement.

Il ne décrit cependant pas le cas de figure assez fréquent selon lequel de nombreux commits successifs sont réalisés avant que l’Intégration Continue ai eu le temps de vérifier le premier. Dans ce cas, une fois qu’elle a terminé, elle prendra la dernière version du code et recommencera. Ce qui peut rendre l’analyse difficile en cas d’échec de l’intégration continue (lequel des commits est coupable ?). Dans ce cas, on pourra demander manuellement à l’outil d’Intégration Continue de tester chaque commit un à un jusqu’à rencontrer l’échec et donc identifier le commit fautif.

En cas d’échec sur une section du pipeline, on s’arrête

Nous l’avons vu, l’un des principes fondamentaux est d’obtenir un feedback au plus tôt afin de limiter les coûts et le stress associés à un défaut. Coût et stress qui ne font que grossir avec le temps. Dès qu’un voyant s’allume, nous avons donc tout intérêt à réagir au plus vite. Il ne s’agit pas forcément de mobiliser toute l’équipe mais à minima une personne doit arrêter ce qu’elle est en train de faire pour retirer le « grain de sable » de l’engrenage. Nous devons par exemple être vigilant le soir lors du dernier commit de la journée en vérifiant que ce dernier a bien passé toute la chaîne automatisée du pipeline avant de partir.

Etape de commit

La première étape du pipeline, celle du commit, est peut être celle qui comporte le plus d’enjeux. L’objectif de cette étape est d’éliminer les build impropres à une livraison en production et de nous avertir au plus tôt en cas de build cassé.

C’est pour cette raison qu’elle couvre généralement les vérifications suivantes :

  • Compilation du code
  • Tests de commit (sous ensemble de tests unitaires automatisés réputés rapides à exécuter et permettant de détecter un maximum de régressions. Ce sous ensemble s’affine au fil de l’eau.)
  • Création des binaires (qui seront utilisés plus tard)
  • Analyse du code (taux de couverture de test, taux de code dupliqué, complexité cyclomatique, nombre de warnings, formatage du code, etc)
  • Préparation des artéfacts (bases de données de test par exemple)
Toutes ces vérifications sont généralement automatisables par les outils d’Intégration Continue.
A chaque modification du code, une nouvelle instance du pipeline est créée. Le paragraphe Outils comporte la capture d’écran d’un outil de Continuous Delivery qui illustre bien ce principe (chaque ligne correspond à une instance du pipeline et donc à un build distinct).

Etape de tests d’acceptation

Cette étape a également une grande importance. Plutôt que de vérifier très localement le bon fonctionnement du code (rôles des tests unitaires automatisés), elle contrôle la bonne couverture du besoin et la non régression fonctionnelle. Elle repose généralement sur des « spécifications par l’exemple » et outils associés (Cucumber, Fitnesse ou Concordium par exemple). Ces tests sont sous la responsabilité collective du métier, des analystes, testeurs et développeurs.

Recourir aux branches avec modération

L’idéal est d’avoir un code constamment livrable malgré les changements constants apportées par l’équipe de développement. Le recours aux branches est tentant. Cependant, il implique une charge de travail importante et des risques élevés même avec les meilleurs outils du monde. L’effort de fusion (merge) et la gestion des conflits (sans avoir forcément les développeurs concernés sous la main) ainsi que la déconnexion à l’Intégration Continue sont de bons exemples de charge de travail et de risques occasionnés par les branches. Plus la durée de vie des branches est longue plus ces contraintes grossissent.

Voici quelques pratiques permettant d’éviter autant que possible le recours aux branches :

  • Nouvelle fonctionnalité : Que faire pour réaliser une nouvelle fonctionnalité ou un nouvel ensemble de fonctionnalités dont le développement peut durer plus d’une semaine alors que notre rythme de livraison en production est hebdomadère ? En commitant sur le trunk les modifications de code (sans branche donc) tout en rendant la nouvelle fonctionnalité invisible pour l’utilisateur tant qu’elle n’est pas terminée (avec une URI dédiée par exemple dans le cas d’un site web).
  • Gros Refactoring : En cas de gros refactoring, découper dans la mesure du possible le travail en petits incréments et faire le refactoring pas à pas sur le trunk en s’appuyant sur la ceintures de tests automatisés. Le découpage demande un peu de créativité mais c’est plus sûr. Cela permet également de pouvoir s’arrêter en cours de route au besoin. Ce qui est très risqué/stressant en cas d’utilisation d’une branche car on vit alors avec la peur d’avoir un trunk qui évolue trop vite et qui rendra le merge douloureux et risqué.
  • Refactoring à grande échelle : Mettre en place une couche d’abstraction au dessus de la zone à refactorer puis réaliser une nouvelle implémentation sous cette couche à côté de l’implémentation existante.

Il est recommandé d’utiliser les branches uniquement dans le cas où ces dernières n’auront pas à être fusionnées. Les branches de release ou de spike (dont le code est jetable) par exemple. Lorsque la fréquence des livraisons en production est élevée (par exemple de l’ordre de la semaine), les branches de release deviennent inutiles. C’est souvent moins coûteux et plus simple d’attendre la prochaine version plutôt qu’avoir recours à un patch et sa branche.

Petit bémol tout de même : Les gestionnaires de version distribués comme GIT changent la donne car ils occasionnent un changement de paradigme. Ce dernier réconcilie peut être le recours aux branches et le Continuous Delivery.

Outils

Exemple d'outil de livraison continue ou continuous delivery

Outil permettant de suivre et gérer les différentes instances du pipeline de déploiement.

Le Continuous Delivery est une démarche très transverses qui touche – directement ou indirectement – à la fois le processus de réalisation, la gestion des tests, les pratiques de développement et la gestion des environnements. Il n’est donc pas surprenant de trouver une grande quantité d’outils en tout genre gratuits ou payants pour atteindre les objectifs visés.

Voici un bref article qui répertorie de tels outils.

Bénéfices

  • Feedback rapide : Plus un défaut est corrigé tard, plus il coûte cher (investiguer, reproduire le défaut, revenir sur du code qui n’est pas forcément le sien, qualifier/estimer/arbitrer/planifier/livrer/tester la correction, etc). Le pipeline de Continuous Delivery offre un feedback rapide et évite ainsi des gaspillages parfois considérables. Un feedback quasi immédiat au niveau de l’Intégration Continue et à la semaine au niveau de l’utilisateur final.
  • Meilleure qualité : Il n’est pas surprenant d’apprendre que les équipes ayant mis en place l’intégralité d’un pipeline de Continuous Delivery en plus de piloter les développements par les tests parviennent aux termes de 6 mois de développement avec une quantité d’anomalies se comptant sur les doigts d’une main. A tel point qu’un outil de suivi d’anomalie ou même un indicateur de volume d’anomalies deviennent tout bonnement inutiles. Le Graal de toute équipe de développement en somme.
  • Moins de stress : Le stress porte principalement sur 2 aspects. Les jalons à tenir qui maintiennent un niveau de stress dans la durée et croissant. Et la livraison qui repose sur une procédure généralement très manuelle et porteuse de nombreux changements (le fruits de plusieurs semaines ou mois de travail). En cas de livraison hebdomadaire avec des procédures automatisées, ces facteurs de stress sont considérablement réduits.
  • Bouton « Retour en arrière » : L’automatisation complète de la livraison à partir d’un binaire déjà construit (identique pour chaque environnement) rend la procédure de livraison rapide quelque soit la version visée. En cas de problème avec la livraison de la dernière version, on pourra revenir en arrière facilement grâce à cette même procédure qui aura alors pour cible les binaires de la version précédente.
  • Week-end pour soi : L’automatisation complète et la fiabilisation de la procédure de livraison rendent cette dernière rapide et presque anecdotique. Si rapide qu’il devient inutile de mobiliser une équipe entière tout un samedi pour assurer la livraison avant que les utilisateurs reprennent le travail.
  • Meilleure relation client – fournisseur : Nous l’avons évoqué en introduction l’objectif premier est la satisfaction du client (et des utilisateurs). Une fois atteint, le principal bénéfice qui en découle est l’acquisition d’une relation de confiance voire de « réel plaisir à travailler ensemble » entre l’équipe de développement, le client et les utilisateurs.
  • Possibilité d’audit de la livraison : Comment auditer une procédure de livraison manuelle qui s’est mal déroulée ? On ne peut pas se reposer sur la procédure papier car elle ne nous dit pas où une erreur humaine à pu se glisser. En revanche une procédure automatique est auditable.

Oui mais…

Beaucoup d’entre nous connaissent sans doute un contexte bien cloisonné au sein duquel l’équipe de développement jette son build ainsi que la procédure d’installation associée par dessus le mur qui la sépare des exploitants (ceux qui mettent l’application en production). Avec toutes le contraintes que ça implique. Que faire dans pareille situation ? Faut il attendre le changement culturel tant attendu qui cessera d’isoler les compétences ? Le risque est d’attendre longtemps – surtout dans une grosse entreprise – même si les courants DevOps prendront sans doute de plus en plus d’ampleur (après tout c’est du bon sens, une fois de plus).

Au lieu d’attendre, c’est sans doute à l’équipe de développement de faire le premier pas. En fournissant avec ses binaires une procédure de livraison ad hoc automatisée type « pousse bouton ». En échange de cette promesse de « don » aux exploitants (heureux de ne pas avoir une centaine de gestes à exécuter avec le risque de se tromper), l’équipe de développement peut légitimement demander un environnement iso-prod (non pas en termes de puissance mais d’architecture technique avec les même version d’OS, même systèmes de répartition de charge, etc) à sa main. C’est cet environnement qui leur permettra de réaliser, utiliser et fiabiliser cette procédure « pousse bouton ». Si le budget d’automatisation est limité, elle automatisera petit bout par petit bout, réduisant toujours un peu plus le délais de livraison et les risques d’erreur.

Pour aller plus loin