Le succès de Scrum a créé un effet secondaire inattendu: dans de nombreuses organisations, le cadre est devenu la méthode par défaut pour tout type de projet, qu’il s’agisse d’une nouvelle initiative, d’une refonte d’infrastructure ou d’une migration réglementaire. Cette généralisation repose sur un malentendu fondamental. Le Guide Scrum définit son propre cadre comme adapté à des problèmes complexes nécessitant des solutions adaptatives, c’est-à-dire des situations où les besoins évoluent, où les solutions émergent par itération et où l’équipe bénéficie d’un retour utilisateur fréquent. Quand ces conditions ne sont pas réunies, forcer Scrum dans un projet crée plus de friction qu’il n’en résout.
Les projets à forfait: une contradiction structurelle
Le cas le plus fréquent d’inadéquation concerne les projets à forfait (fixed-price contracts). Le modèle économique de Scrum repose sur un principe clair: le coût et le délai sont fixes (un nombre défini de sprints avec une équipe stable), mais le périmètre est variable. Le Product Owner (le responsable du produit) priorise le backlog (la liste ordonnée des travaux) en fonction de la valeur, et l’équipe livre ce qui est faisable dans le temps imparti.
Un contrat au forfait fonctionne exactement à l’inverse. Le client a acheté un périmètre précis pour un prix défini. Réduire ce périmètre en cours de route, même pour de bonnes raisons, constitue un manquement contractuel. Dans cette configuration, les sprints deviennent une simple méthode de découpage du calendrier, pas un mécanisme d’adaptation. Le sprint review (la revue de ce qui a été livré à la fin de chaque cycle) perd sa fonction principale, qui est de permettre au client de réorienter les priorités, puisque les priorités sont déjà contractuellement figées.
Cela ne signifie pas qu’une approche itérative est impossible dans un contexte contractuel. Mais elle exige des clauses spécifiques (enveloppes de changement, priorisation conjointe, acceptation progressive) et une maturité relationnelle entre client et prestataire qui sont rarement présentes au démarrage d’un projet.
Infrastructure et migration: où est l’incrément de valeur?
Scrum repose sur l’idée d’un incrément livrable à chaque sprint, un morceau de produit fonctionnel qui apporte de la valeur à l’utilisateur final. Ce principe fonctionne bien pour le développement de fonctionnalités logicielles ou la construction d’un service, mais il devient artificiel dans les projets d’infrastructure.
Prenons une migration de base de données. Le travail suit une séquence technique largement prédéterminée: analyse de l’existant, conception du schéma cible, développement des scripts de migration, tests de non-régression, bascule. Chaque étape dépend de la précédente, et aucune ne constitue un “incrément de valeur” pour l’utilisateur final avant la bascule complète. Découper ce travail en sprints est possible, mais le backlog qui en résulte n’est pas réellement priorisable: on ne peut pas décider de migrer la moitié des tables et de livrer cette moitié en production.
Le même problème se pose pour les projets de replatforming, de mise en place d’infrastructure réseau ou de déploiement d’outils internes. Le travail est souvent séquentiel par nature, les dépendances techniques sont fortes, et la notion de priorisation par la valeur perd son sens quand le produit n’est fonctionnel qu’une fois l’ensemble terminé.
Projets réglementaires: quand la documentation n’est pas une option
Dans les secteurs bancaire, pharmaceutique ou de la construction, la réglementation impose une documentation préalable détaillée et une traçabilité complète des décisions. Un projet de mise en conformité réglementaire ne peut pas fonctionner sur le principe du “discovering as we go” qui est au fondement de l’agilité.
Intentionnellement minimale, la documentation en Scrum reflète la position du Manifeste Agile qui valorise “un logiciel fonctionnel plus qu’une documentation exhaustive”, ce qui est parfaitement raisonnable dans un contexte de développement produit. Mais quand un audit réglementaire exige la preuve que chaque exigence a été spécifiée, validée, implémentée et testée selon un protocole défini, le minimalisme documentaire devient un risque juridique.
Des adaptations existent: certaines équipes maintiennent une documentation réglementaire en parallèle du processus Scrum, avec des “definition of done” (les critères que chaque élément de travail doit satisfaire pour être considéré comme terminé) qui incluent la production documentaire. Mais ces adaptations alourdissent considérablement le cadre et posent la question de savoir si l’on pratique encore Scrum ou si l’on a créé un hybride qui n’a plus que le nom en commun avec le cadre original.
La question des équipes distribuées
Le Guide Scrum a été mis à jour en 2020 pour supprimer la référence explicite à la co-localisation, mais l’ensemble du cadre repose sur des mécanismes de communication qui présupposent une proximité forte. La mêlée quotidienne de quinze minutes fonctionne quand tout le monde est dans la même pièce ou le même fuseau horaire, mais elle devient un exercice pénible quand l’équipe est répartie entre Zurich, Bangalore et San Francisco, avec des plages de chevauchement réduites à une ou deux heures par jour.
Les organisations distribuées qui réussissent avec Scrum le font généralement en constituant des équipes co-localisées par site plutôt qu’en dispersant les membres d’une même équipe. Lorsque cette configuration n’est pas réalisable, les mécanismes de communication asynchrone (documentation écrite, décisions enregistrées, mises à jour différées) prennent une importance que Scrum n’est pas conçu pour gérer.
Choisir le cadre en fonction du projet
L’erreur n’est pas d’utiliser Scrum: le cadre a fait ses preuves dans les contextes pour lesquels il a été conçu. L’erreur est de l’appliquer par défaut, sans évaluer si les conditions nécessaires sont réunies. Un chef de projet qui démarre un nouveau mandat a tout intérêt à se poser quelques questions concrètes avant de choisir son approche: le périmètre est-il susceptible d’évoluer? L’équipe peut-elle livrer des incréments de valeur à intervalles courts? Le client est-il disponible pour donner du feedback régulier? La réglementation permet-elle une approche itérative?
Si la réponse à plusieurs de ces questions est non, un cadre prédictif classique, une approche hybride ou un framework comme HERMES (la méthode de gestion de projet de la Confédération suisse, structurée en phases avec une gouvernance claire) peuvent s’avérer mieux adaptés. Le pragmatisme n’est pas un aveu de faiblesse: c’est la marque d’un chef de projet qui comprend ses outils assez bien pour savoir quand ne pas les utiliser.