Le Manifeste Agile (Agile Manifesto), signé en 2001 par 17 développeurs logiciels réunis dans une station de ski de l’Utah, tient en quatre phrases. Vingt-cinq ans plus tard, ces quatre phrases sont citées dans la plupart des formations en gestion de projet, bien au-delà du développement informatique. Elles sont aussi, dans une proportion remarquable, mal comprises.
Le malentendu repose sur un seul mot: “over”, traduit en français par “plus que” ou “plutôt que”. Beaucoup de praticiens lisent ce mot comme un synonyme de “au lieu de”. Cette lecture transforme un texte de priorisation en manifeste d’abolition, avec des conséquences concrètes sur la manière dont les organisations conduisent leurs projets.
Ce que le texte dit, littéralement
Le Manifeste formule quatre préférences:
- Les individus et leurs interactions, plus que les processus et les outils
- Un logiciel qui fonctionne, plus qu’une documentation exhaustive
- La collaboration avec les clients, plus que la négociation contractuelle
- L’adaptation au changement, plus que le suivi d’un plan
Chaque formulation suit la même structure: un élément prioritaire “plus que” un élément secondaire. Le Manifeste précise d’ailleurs, dans une ligne souvent ignorée: “Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.” Les processus, la documentation, les contrats et les plans conservent donc leur valeur. Ils passent simplement au second rang quand un arbitrage s’impose.
Quand “plus que” devient “au lieu de”
La lecture binaire produit des résultats prévisibles. Une organisation qui supprime ses processus de reporting au nom de la première valeur ne libère pas la collaboration: elle crée un vide d’information où chacun improvise. Une équipe qui abandonne toute documentation au nom de la deuxième valeur ne gagne pas en agilité: elle perd la mémoire de ses propres décisions.
Ce glissement explique une part significative de ce que les observateurs appellent le “cherry-picking agile”: l’adoption sélective de pratiques agiles sans compréhension des principes sous-jacents. L’organisation supprime ce qui la contraignait (documentation, planification, formalisation) et conserve ce qui l’arrange (flexibilité, réactivité), puis s’étonne de produire du chaos plutôt que de l’agilité.
Les individus plus que les processus
La première valeur ne demande pas de supprimer les processus. Elle demande de les considérer comme des outils au service des personnes, pas comme des fins en soi. Quand un processus de validation mobilise trois niveaux hiérarchiques pour une décision que l’équipe pourrait prendre en réunion, c’est le processus qui doit s’adapter.
En gestion de projet hors contexte informatique, cette valeur a une portée directe. Un chef de projet qui pilote la construction d’un bâtiment ou la réorganisation d’un service n’a pas besoin de supprimer ses processus de suivi. Il doit s’assurer que ces processus facilitent la coordination de l’équipe plutôt que de la ralentir. La nuance est entre un reporting qui informe et un reporting qui occupe.
Le résultat concret plus que la documentation exhaustive
La deuxième valeur est celle qui nécessite la transposition la plus importante quand on sort du contexte logiciel. “Working software” (logiciel fonctionnel) devient, dans un projet non-IT, le livrable concret, le résultat tangible et vérifiable.
Un cahier des charges de 200 pages qui décrit un futur système sans qu’aucun prototype n’ait été testé illustre le déséquilibre que le Manifeste cherche à corriger. La documentation n’est pas inutile: un procès-verbal de réception, un cahier des charges fonctionnel ou un registre des décisions restent des outils nécessaires. Ce qui pose problème, c’est la documentation produite par réflexe organisationnel plutôt que par nécessité opérationnelle, celle que l’on rédige parce que le processus l’exige et non parce qu’un lecteur identifié en a besoin. La valeur invite à ne pas confondre l’avancement de la documentation avec l’avancement du projet lui-même.
La collaboration plus que le contrat
La troisième valeur est peut-être celle qui suscite le plus de résistance dans les environnements non-IT, où les contrats structurent les relations avec les fournisseurs, les partenaires et les clients. Le Manifeste ne propose pas de travailler sans contrat. Il propose que, face à une divergence entre ce que le contrat prévoit et ce que le client exprime, la conversation directe prime sur l’application mécanique des clauses.
En pratique, cette valeur s’applique à tout projet impliquant des parties prenantes (stakeholders, c’est-à-dire les personnes ou entités qui ont un intérêt dans le projet) externes. Un contrat à forfait qui ne prévoit aucune évolution du périmètre (scope, soit l’ensemble des livrables et travaux attendus) pousse les deux parties vers la rigidité. La collaboration, dans ce contexte, consiste à maintenir un dialogue continu sur les besoins réels plutôt que de s’en remettre exclusivement aux spécifications initiales. Dans les marchés publics suisses ou européens, où le cadre contractuel est particulièrement formalisé, cette tension est d’autant plus visible: le contrat fixe les obligations légales, mais seul un échange régulier entre le mandant et le prestataire permet d’ajuster les priorités quand les conditions du terrain évoluent. Un avenant contractuel négocié et signé six mois après le lancement du projet ne remplace pas une conversation tenue dès que le besoin change.
L’adaptation plus que le plan
La quatrième valeur est probablement la plus intuitive et la plus mal appliquée: tout chef de projet sait que les plans changent, mais certaines organisations en concluent que planifier est inutile.
La planification en contexte agile n’est pas absente: elle est fréquente et courte. Les 12 principes du Manifeste recommandent de livrer fréquemment, par itérations de quelques semaines. Chaque itération, appelée sprint (période de travail de 2 à 4 semaines) dans le cadre Scrum, fait l’objet d’une planification. La différence avec une approche prédictive classique n’est pas l’absence de plan, c’est l’horizon du plan et la facilité avec laquelle il peut être révisé.
Pour un projet de déménagement d’entreprise, cela signifie qu’un planning général reste nécessaire pour coordonner les corps de métier, mais que les détails de chaque phase se précisent au fur et à mesure, en fonction des retours du terrain. Le plan directeur fixe les jalons (date de résiliation du bail, livraison des nouveaux locaux, transfert des équipements), tandis que l’organisation concrète de chaque étape s’affine à mesure que l’information devient disponible.