Quand le produit fonctionne mais ne peut pas être déployé
Il existe un scénario que connaissent la plupart des chefs de projet ayant travaillé en environnement technique: l’équipe a livré toutes les fonctionnalités prévues, les tests sont passés, les parties prenantes métier ont validé, et pourtant la mise en production est reportée. Il manque la documentation opérationnelle, les outils de supervision ne sont pas configurés, les procédures de support n’existent pas, les droits d’accès en production ne sont pas définis.
Le produit est fonctionnel mais pas encore exploitable, distinction que la plupart des plans de projet ne formalisent pas. Cet écart, rarement anticipé, est à l’origine de nombreuses mises en production chaotiques.
MVP et MVS: deux notions complémentaires
Le concept de MVP (Minimum Viable Product, produit minimum viable) est largement adopté en gestion de projet agile. Il désigne la version la plus simple d’un produit permettant de valider une hypothèse ou de répondre à un besoin essentiel. La notion est utile pour cadrer le périmètre fonctionnel et éviter la surconception.
Moins répandue est la notion de MVS, le Minimum Viable Service: l’ensemble des éléments nécessaires pour qu’un produit puisse être exploité en production de manière pérenne. Le MVS englobe la documentation opérationnelle (runbooks, procédures d’incident), les outils de monitoring et d’alerte, les procédures de sauvegarde et de restauration, la configuration des accès et des droits et les processus de support de premier niveau.
Un MVP peut être techniquement complet sans constituer un MVS. L’erreur fréquente est de considérer que la livraison fonctionnelle équivaut à la capacité de mise en production. Le chef de projet qui ne distingue pas ces deux périmètres découvre l’écart au pire moment: quand tout le monde pense que le projet est terminé.
Pourquoi cet écart existe
L’écart entre MVP et MVS s’explique par la structure même de la plupart des projets techniques. Les exigences fonctionnelles sont portées par les parties prenantes métier, qui savent ce qu’elles veulent. Les exigences d’exploitation sont portées par les équipes d’opérations, qui sont rarement impliquées dans le cadrage du projet.
Le résultat est un plan de projet qui détaille les fonctionnalités à développer mais qui traite l’exploitabilité comme une évidence. Les activités de préparation à la mise en production apparaissent, quand elles apparaissent, dans les dernières semaines du planning, coincées entre la fin des tests et la date de déploiement.
Martin Fowler observe que les équipes qui investissent dans la qualité interne, dont fait partie la préparation à l’exploitation, maintiennent leur capacité de livraison dans le temps. Celles qui l’ignorent accumulent une dette qui se paie en incidents de production, en maintenance réactive et en frustration des équipes de support.
Intégrer le MVS dès le cadrage
La solution consiste à intégrer les exigences d’exploitation dans le périmètre du projet dès le cadrage, au même titre que les exigences fonctionnelles. Plusieurs actions concrètes permettent d’y parvenir.
La première est d’impliquer les équipes d’exploitation dans l’atelier de cadrage. Leur présence permet d’identifier les exigences de monitoring, de sauvegarde et de support avant que l’architecture ne soit figée. La seconde est de formaliser une checklist de mise en production (production readiness checklist) qui couvre les exigences non fonctionnelles (NFRs, pour Non-Functional Requirements): SLA (Service Level Agreement, accord de niveau de service), performance, sécurité et scalabilité. Cette checklist devient un livrable du projet à part entière, validé conjointement par les équipes de développement et d’exploitation.
Les environnements de test et de pré-production doivent également figurer dans le planning comme des livrables avec des responsables et des échéances, pas comme des prérequis implicites. Le rapport DORA 2023 montre que les organisations performantes se distinguent par une infrastructure flexible et des pratiques d’intégration continue, deux éléments impossibles sans environnements correctement provisionnés.
Définir les critères de “done” pour l’exploitation
La notion de “definition of done” est familière aux équipes agiles, mais elle se limite souvent aux critères fonctionnels et techniques: le code est écrit, testé, documenté et intégré. Le passage au MVS exige d’élargir cette définition pour inclure les critères d’exploitation.
Un livrable n’est véritablement terminé que lorsque les runbooks sont rédigés et validés par l’équipe de support, que les alertes de monitoring sont configurées et testées, que la procédure de rollback a été répétée au moins une fois et que l’astreinte est organisée pour la période suivant la mise en production. Tant que ces éléments ne sont pas en place, le produit reste dans un état intermédiaire où il fonctionne en environnement contrôlé mais où personne ne peut garantir son comportement en conditions réelles.
Formaliser ces critères dans le plan de projet oblige toutes les parties prenantes à reconnaître que la mise en production est un processus, pas un événement. Le chef de projet qui inscrit ces activités dans le calendrier, avec des responsables nommés et des délais réalistes, évite la compression habituelle des tâches d’exploitation dans les derniers jours du planning.
La sécurité comme composante du service
La sécurité illustre bien la tension entre MVP et MVS. Un produit peut être fonctionnel sans être sécurisé. Le RGPD impose pourtant le principe de Security by Design: la sécurité doit être intégrée dès la conception, pas ajoutée en fin de cycle.
Pour le chef de projet, cela signifie identifier les exigences de sécurité et de confidentialité en amont: où les données sont-elles hébergées? Quels niveaux de chiffrement sont requis? Qui a accès à quoi? Ces questions relèvent du MVS, pas du MVP, et elles doivent être traitées en parallèle du développement fonctionnel.
Planifier des revues de sécurité dans le calendrier du projet, au même titre que les revues fonctionnelles, évite la situation classique où un audit de sécurité en fin de projet révèle des vulnérabilités qui nécessitent des modifications architecturales.
Gérer les dépendances entre produit et service
Un projet technique s’intègre dans un écosystème: APIs tierces, bases de données existantes, services cloud, systèmes d’authentification. Ces dépendances concernent autant le MVP (le produit doit s’interfacer) que le MVS (le service doit fonctionner quand une dépendance est indisponible).
La cartographie des dépendances, menée avec l’architecte technique, doit couvrir les deux dimensions: quelles interfaces sont nécessaires au fonctionnement et quelles procédures de dégradation sont prévues en cas de défaillance d’un composant externe. Le standard ISO/IEC 25010 définit la fiabilité et la disponibilité comme des caractéristiques qualité du système, ce qui confirme leur place dans le périmètre projet.
Le rôle du chef de projet dans cette distinction
Le chef de projet ne définit pas l’architecture technique ni les procédures d’exploitation. Son rôle est de s’assurer que ces sujets sont traités, par les bonnes personnes, au bon moment. Poser la question “Ce produit est-il exploitable en l’état?” à chaque revue de jalon force l’équipe à confronter la réalité du MVS, pas seulement celle du MVP.
Cette vigilance suppose de dialoguer avec deux mondes qui communiquent peu naturellement: les équipes de développement, focalisées sur les fonctionnalités, et les équipes d’opérations, focalisées sur la stabilité. Le chef de projet qui assure cette coordination entre les deux équipes réduit le risque de livrer un produit que personne ne peut exploiter.