Être prêt pour la prod : checklist prod-ready

Passer en production nous permet de tester des hypothèses qui ne peuvent être éprouvées qu’en situation réelle, un moment où le feedback des utilisateurs concrétise la pertinence de nos choix. Au plus tôt on y arrive, le mieux c'est. Mais la mise en production ne se résume pas à déployer du code ; elle doit être préparée avec soin. On a besoin de trouver un équilibre entre rapidité de mise à disposition aux utilisateurs et stabilité du service. Aller en production mobilise une multitude de pratiques qui ne s’emploient pas au hasard.

C'est pourquoi nous avons créé un support de discussion. Son but ? Offrir un document d'appui pour initier des conversations et prendre des décisions adaptées aux moments-clés d'un projet afin d’optimiser la réussite de mise en production. Nous l’avons construit depuis nos expériences. Cet article en est la présentation. N’hésitez pas à l’intégrer dans vos projets !

Découvrez-le ici !

La checklist prod-ready

L’idée première qui nous est venue était de créer une checklist pour vérifier que chaque caractéristique d’une “bonne production” soit bien implémentée. Cependant, nous nous sommes trouvés face à un mur : créer une checklist universelle s'est avéré impossible. Chaque contexte, chaque environnement de production et même chaque niveau d’avancement de projet est unique. Une liste de points qu’on doit cocher rigoureusement ne peut répondre à cette diversité.

Nous nous sommes donc demandé : comment faire évoluer notre format de checklist vers un outil utile et adaptable à tous les contextes ?

Pour répondre à cette problématique, nous avons identifié un ensemble de capacités essentielles pour partir en production. Une capacité, c'est une combinaison de pratiques, de méthodes et d’outils qui permettent de fiabiliser l’opération de la production.

Nous avons également distribué ces capacités de façon à ce qu’elles correspondent à différents moments-clés dans la vie d’un projet :

  • Lors de la première mise en service : quand votre produit fait ses premiers pas.
  • Avant chaque mise en service : pour éviter les erreurs coûteuses.
  • Au changement d’échelle : lorsque le projet grandit et se complexifie.
  • De manière récurrente : quand le projet dépend de facteurs indépendants de son rythme de vie.

Cette catégorisation devait répondre à la question : « Quel est le moment idéal pour mettre en place cette capacité? », signifiant que vous aurez un meilleur ROI si vous mettez en place la capacité à ce moment-là.

Afin de vous éclairer sur le choix des moments-clés, nous allons maintenant voir ce qu’il signifie en détail.

Comprendre les moments-clés

un schéma qui représente les moments clés d'un projet, avant la première mise, en service, avant chaque mise en service, en cas de changement d'échelle, de manière récurrent

Avant la 1ère Mise En Service (MES)

Ce premier jalon représente l’ensemble des prérequis à la première mise en service. L’objectif est de garantir une ouverture de service sécurisée et stable. Cela inclut la préparation d’actions et de dispositifs spécifiques : par exemple, la mise en place d’un dispositif de support exceptionnel pour recueillir et traiter les premiers retours des utilisateurs, permettant ainsi de réagir rapidement aux éventuels problèmes. Par la suite, ce même dispositif peut être pérennisé, évoluer, ou être sous-traité selon l’évolution des besoins du projet.

Avant chaque Mise En Service

Il est fort probable que les nouvelles fonctionnalités de votre service le soumettent à de nouvelles pressions, contraintes ou usages. Ainsi, pour chaque nouvelle mise en production, il est essentiel de réviser et d'ajuster les pratiques et outils déjà en place afin de s’assurer qu’ils répondent toujours aux besoins actuels. Cela peut inclure, par exemple, la mise à jour des processus de mise en service.

Récurrent / sanity check

Certains éléments nécessitent une vigilance continue, indépendamment des phases de mise en production. Ce moment inclut des vérifications et des mises à jour périodiques en fonction de l’évolution de l’environnement externe et interne. Par exemple, cela peut être le cas pour des changements dans les réglementations légales, des mises à jour liées à des failles de sécurité, ou encore des modifications dans les dépendances techniques du SI.

Changement d'échelle

Le changement d'échelle représente un moment critique où des transformations significatives, qu'elles soient organisationnelles ou techniques, remettent en question les pratiques de gestion en production. Ce moment est souvent associé à des étapes de croissance, telles que l’ajout de nouvelles typologies d’utilisateurs, l’ouverture du service à l’international ou encore une augmentation importante du trafic. Notez que pour un SI avec des enjeux d’échelle élevés, les besoins de fiabilisation sont plus grands et donc que ces capacités peuvent être discutées avant la première MES.

Mode de d’emploi

Le but de la checklist est de vous partager nos convictions, de manière structurée, afin de vous informer, de vous orienter et de vous aider à convaincre à propos des capacités importantes pour votre contexte, et de quand il est important de les mobiliser. Elle peut vous aider comme support de discussion, d’arbitrage ou de décision.

Qui peut s’en servir

Toute personne qui a son mot à dire sur les NFRs (Non-Functional Requirement) et qui comprend ses enjeux : développeur, tech lead, PO, architecte, engineering manager, etc.

Comment s’en servir

  1. Identifiez votre moment clé : Repérez l’étape où se trouve votre projet (première mise en service, montée en échelle, mise à jour récurrente, etc.).
  2. Explorez les capacités associées : Consultez la checklist des capacités proposées pour ce moment et identifiez qui mobiliser pour évaluer leur pertinence dans votre contexte.
  3. Déclencher la discussion : Appuyez-vous sur cet outil pour structurer vos échanges, prioriser vos efforts et arbitrer vos décisions.
  4. Mettez en œuvre, même en retard : Chaque capacité est associée à un moment idéal, mais il n’est jamais trop tard pour la déployer. Si vous avez manqué le coche, mieux vaut agir tard que pas du tout. De fait, pensez à explorer les capacités antérieures à votre moment.

Quand la (re)consulter

Voici quelques exemples de rituels idéals pour se servir de l’outil :

  • Avant la première mise en service : à aborder lors des étapes de cadrage du projet, dans les sessions de PI Planning (pour les environnements SAFe), ou encore à travers un atelier de gestion des risques en début de projet.
  • Avant chaque mise en service : à aborder lors de la révision du document d’exploitation, une pratique qui permet d’anticiper les ajustements nécessaires et de maintenir la cohérence dans les déploiements successifs.
  • Changement d’échelle : à aborder lors du cadrage d’une nouvelle épique, de la définition de la stratégie de déploiement à l’échelle d’un produit, du cadrage de l’intégration d’une acquisition au sein du SI, ou dans un atelier de gestion des risques pour évaluer l’impact des nouvelles exigences sur les pratiques de production.
  • Récurrent en mode sanity check : à aborder lors de rétrospectives techniques, les comités d’architecture, ou encore les sessions d’Inspect & Adapt pour les environnements SAFe.

Et vous pouvez aussi le faire de manière complètement décorrélé des exemples cités (par exemple, en lisant cet article et en lançant une discussion sur Slack). L’important étant surtout de “mettre le sujet sur la table”.

À vos feedbacks !

Cet outil de discussion a été conçu pour donner une structure flexible et adaptable, permettant à chaque équipe de naviguer dans les complexités de la mise en production sur tout son cycle de vie. Nous vous recommandons fortement de vous l’approprier en y ajoutant des capacités qui seraient propres à vos contextes. Alors découvrez l’outil pour structurer vos échanges ici et n’hésitez pas à nous donner vos feedbacks !