Les 4 valeurs agiles : des arbitrages, pas des slogans

Les 4 valeurs agiles, ou valeurs du manifeste agile, sont les quatre préférences énoncées en 2001 par les signataires du manifeste : les individus et leurs interactions, des logiciels opérationnels, la collaboration avec les clients et l’adaptation au changement. Chacune est écrite comme un arbitrage entre deux termes, et non comme une interdiction.

L’histoire du document et ses 12 principes sont traités dans mon article sur le manifeste Agile : cet article-ci ne les reprend pas. Il porte sur un seul point, celui qui se perd presque toujours en chemin. La formule « plus que » ne supprime pas le second terme, et ne pas le voir produit les contresens les plus répandus de l’agilité : « pas de documentation », « pas de contrat », « pas de plan ».

Les 4 valeurs agiles : le texte exact et le sens de « plus que »

Le texte des quatre valeurs, mot pour mot

Le manifeste tient en quelques lignes, et la traduction française de référence, publiée sur agilemanifesto.org, énonce les valeurs ainsi :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels 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

Une seconde traduction française circule, celle de manifesteagile.fr, qui écrit « de préférence à » et remplace « logiciels » par « solutions opérationnelles ». L’écart est instructif : le manifeste a été rédigé par des développeurs, pour du logiciel, mais l’arbitrage qu’il pose vaut pour n’importe quel livrable. C’est aussi pour cela que ces quatre phrases se citent aujourd’hui bien au-delà des équipes techniques.

« Plus que » ne veut pas dire « au lieu de »

Le texte ne s’arrête pas aux quatre lignes. Il ajoute immédiatement une phrase qui en commande toute la lecture, et qui est presque toujours omise dans les reprises :

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Autrement dit : les processus, la documentation, le contrat et le plan ont de la valeur, et le manifeste le dit noir sur blanc. Une valeur agile n’est donc pas une règle d’exclusion, c’est une règle de priorité — elle ne s’active que lorsque les deux termes entrent en conflit. Hors conflit, elle ne demande rien du tout. Ce détail change tout à l’usage : on ne cite pas une valeur pour se dispenser d’un travail, on la cite pour trancher un désaccord.

Valeur	Ce qu’elle privilégie en cas de conflit	Ce qu’elle ne supprime pas	Le contresens courant
Individus et interactions	La décision de ceux qui font le travail	Les processus et les outils	« On travaille sans processus »
Logiciels opérationnels	Ce qui tourne et peut être essayé	La documentation utile	« On ne documente pas »
Collaboration client	Décider ensemble de la suite	Le contrat et son cadre	« Il n’y a pas de contrat »
Adaptation au changement	Mettre le plan à jour	La planification	« On ne planifie pas »

Valeurs agiles, principes agiles, valeurs Scrum : trois textes différents

Trois séries de valeurs circulent sous le mot « agile », et les confondre fait perdre beaucoup de temps. Les 4 valeurs sont le manifeste lui-même : quatre arbitrages, rien de plus. Les 12 principes en sont la déclinaison opérationnelle — fréquence de livraison, place du client, rythme soutenable, accueil des changements de besoin. Ils forment un second texte, publié avec le manifeste, que je détaille dans l’article dédié. La hiérarchie est simple : les valeurs donnent le cap, les principes indiquent la conduite, et les cadres de travail comme Scrum ou Kanban fournissent les pratiques. C’est exactement le rôle d’un framework agile.

Les 5 valeurs Scrum — focus, courage, ouverture, engagement, respect — sont tout autre chose, et c’est la confusion la plus fréquente. Elles n’appartiennent pas au manifeste : elles figurent dans le Scrum Guide, publié bien après, et décrivent des comportements attendus d’une équipe. Les valeurs agiles arbitrent entre deux options de conduite de projet ; les valeurs Scrum qualifient une manière de travailler ensemble. On peut réciter les cinq sans avoir jamais tranché selon les quatre. Le détail est dans mon article sur les 5 valeurs scrum, et la frontière entre les deux univers dans méthode agile vs scrum.

En vidéo : « Les 4 valeurs du Manifeste Agile » (Jean-François Erlem), une présentation des quatre énoncés en français.

Les individus et leurs interactions plus que les processus et les outils

L’arbitrage porte sur l’autorité. Quand une procédure et la personne qui fait le travail ne disent pas la même chose, la valeur tranche : on écoute la personne. Concrètement, c’est le droit pour une équipe de modifier sa propre façon de travailler sans en demander l’autorisation à l’échelon qui a écrit le processus.

Ce que cette valeur autorise : des processus, et beaucoup. Une cadence de livraison, une revue de code, un point de synchronisation quotidien sont des processus, et aucun n’est écarté par le manifeste. Elle autorise aussi les outils — un outil de suivi, un dépôt de code, une chaîne d’intégration. La condition tient au sens de service : le processus existe pour l’équipe, et non l’équipe pour le processus. Un test simple permet de savoir de quel côté on se trouve : demandez qui a le droit de changer la règle. Si c’est l’équipe qui l’applique, la valeur est respectée. Si c’est une instance extérieure et qu’il faut un dossier pour obtenir une dérogation, l’arbitrage a été rendu dans l’autre sens.

Le contresens : « l’agilité, c’est travailler sans processus »

Cette lecture est la plus commode, parce qu’elle transforme une exigence en dispense. Elle ne résiste pas au texte : une équipe sans cadence, sans définition de ce qui est terminé et sans moment d’échange structuré n’est pas agile, elle est désorganisée. La sprint retrospective en est la meilleure illustration — c’est un processus, formel et régulier, dont l’objet est précisément de laisser l’équipe modifier ses propres règles. Retirer les processus ne libère pas les interactions : cela les remplace par de l’improvisation.

Des logiciels opérationnels plus qu’une documentation exhaustive

L’arbitrage porte sur la preuve d’avancement. Un projet a-t-il progressé parce que le dossier de conception est signé, ou parce qu’une fonctionnalité tourne et peut être essayée ? La valeur tranche pour le second, et elle a une conséquence directe sur la façon de rendre compte : ce qui se démontre en fonctionnement compte davantage que ce qui se raconte dans un rapport.

Ce qu’elle autorise : écrire. Le mot qui fait l’arbitrage est « exhaustive », pas « documentation ». Ce qui est visé, c’est le document qui décrit par avance un système entier et se périme à la première décision contraire — pas la note de trois pages qui évite à quatre personnes de se tromper. La différence tient à un critère unique : ce document a-t-il un lecteur identifié, et une décision à éclairer ?

• La definition of done — sans elle, « terminé » n’a pas de sens partagé.
• Les critères d’acceptation d’une fonctionnalité, qui disent ce que l’on vérifie avant de la considérer livrée.
• Une spec produit sur ce qui est complexe, contre-intuitif ou coûteux à redécouvrir.
• La documentation d’exploitation, celle dont dépend la personne d’astreinte en pleine nuit.
• Tout ce qu’impose la conformité du secteur concerné, qui ne se négocie pas au nom d’une valeur.

Le contresens : « en agile, on ne documente pas »

C’est probablement le plus coûteux des quatre, parce qu’il ressemble à une économie. Ce que la valeur demande est un déplacement, pas une suppression : documenter ce qui sert à quelqu’un, au moment où cela lui sert, plutôt que constituer un dossier complet avant même d’avoir appris quoi que ce soit. Un MVP livré sans aucune trace écrite n’illustre pas cette valeur : il déplace simplement le coût sur la personne suivante. La bonne question n’est jamais « faut-il documenter ? », mais « qui lira ce document, et pour décider quoi ? ».

La collaboration avec les clients plus que la négociation contractuelle

L’arbitrage porte sur la manière de traiter le désaccord. Deux réflexes s’opposent : rouvrir le contrat pour établir qui avait raison, ou s’asseoir avec le client pour décider ensemble de la suite. La valeur tranche pour le second, et elle a un prix rarement annoncé — elle suppose que le client soit disponible pendant le projet, et pas seulement à son lancement puis à sa livraison.

Ce qu’elle autorise : un contrat, et un contrat solide. Le terme arbitré est « négociation », c’est-à-dire l’usage du contrat comme arme lorsque la relation se dégrade. Rien dans le manifeste ne demande de travailler sans engagement écrit, et ce serait un mauvais conseil pour le client comme pour le prestataire.

• Le budget et sa durée, éventuellement révisables à intervalles définis.
• La cadence de livraison et les moments où le client se prononce.
• La manière dont une priorité se change, plutôt que la liste figée de ce qui sera livré.
• Les critères de recette, la propriété du code, la réversibilité et les conditions de sortie.

Le contresens : « en agile, il n’y a pas de contrat »

Aucune organisation n’engage un budget sans écrit, et un prestataire qui présenterait l’agilité comme une raison de ne pas s’engager donnerait surtout un signal d’alarme. La difficulté réelle est ailleurs : un contrat au forfait qui fige à la fois une liste de fonctionnalités et une date rend cette troisième valeur inapplicable, puisque le moindre changement passe par un avenant. Le point de tension est donc contractuel avant d’être méthodologique — et c’est le sujet à traiter avant de choisir un cadre de travail, pas après.

L’adaptation au changement plus que le suivi d’un plan

L’arbitrage porte sur le statut du plan. Dans une conduite de projet classique, un écart au plan est un incident à corriger. Ici, c’est une information : si la réalité contredit le plan, on met le plan à jour. C’est la valeur la plus contre-intuitive pour une direction, parce qu’elle demande de renoncer à la promesse la plus confortable — celle d’un périmètre connu douze mois à l’avance.

Ce qu’elle autorise : planifier, et souvent. Le manifeste ne compare pas le plan au néant ; il compare le suivi d’un plan à l’adaptation. Ce qui change n’est donc pas l’existence du plan, mais sa fréquence de révision et la nature de ce qu’il engage.

• Une trajectoire à horizon lisible, exprimée en intentions plutôt qu’en dates de livraison.
• Un backlog produit ordonné : c’est un plan, simplement révisable.
• Les jalons réellement contraints de l’extérieur — échéance réglementaire, saisonnalité commerciale, campagne déjà engagée.
• La capacité disponible sur le cycle en cours, seul horizon sur lequel un engagement ferme a du sens.

Le contresens : « en agile, on ne planifie pas »

Une équipe qui ne planifie rien ne s’adapte pas : elle réagit. La nuance est décisive, car une organisation qui change d’avis en permanence sans jamais terminer ce qu’elle a commencé produit les mêmes dégâts qu’un plan rigide, avec en plus l’épuisement des équipes. S’adapter suppose un plan auquel se comparer — sans lui, il n’y a rien à adapter, seulement des priorités qui se succèdent.

Un mot personnel pour finir. Après plus de dix ans passés dans des cadres agiles, le mésusage que je rencontre le plus souvent n’est pas l’ignorance du texte, c’est son invocation pour justifier ce qui avait déjà été décidé : « adaptation au changement » pour ne pas trancher, « logiciels opérationnels » pour ne pas écrire, « collaboration » pour ne pas cadrer. Les quatre valeurs ne dispensent de rien. Elles disent seulement, quand deux options légitimes s’affrontent, laquelle doit gagner.

FAQ — Tout savoir sur les 4 valeurs agiles

Quelles sont les 4 valeurs agiles ?

Les individus et leurs interactions plus que les processus et les outils ; des logiciels opérationnels 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. Ce sont les quatre préférences énoncées par le manifeste agile en 2001.

Quelle est la différence entre les valeurs et les principes agiles ?

Les quatre valeurs donnent le cap : ce sont des arbitrages, à utiliser lorsque deux options s’opposent. Les douze principes en sont la déclinaison opérationnelle : ils précisent la fréquence de livraison, la place du client, le rythme de travail et la manière d’accueillir un changement de besoin. Les valeurs d’abord, les principes ensuite.

Les 4 valeurs agiles sont-elles les mêmes que les 5 valeurs Scrum ?

Non, ce sont deux textes distincts. Les quatre valeurs agiles viennent du manifeste de 2001 et arbitrent des choix de conduite de projet. Les cinq valeurs Scrum — focus, courage, ouverture, engagement, respect — figurent dans le Scrum Guide et décrivent des comportements attendus d’une équipe.

Que signifie « plus que » dans les 4 valeurs agiles ?

Une priorité, pas une exclusion. Le manifeste ajoute explicitement qu’il reconnaît la valeur des seconds éléments mais privilégie les premiers. La formule sert à trancher quand les deux termes entrent en conflit ; hors conflit, les deux gardent leur utilité.

L’agilité interdit-elle la documentation ?

Non. Le mot arbitré est « exhaustive » : ce qui est écarté, c’est le dossier qui décrit tout par avance et se périme aussitôt. La definition of done, les critères d’acceptation, la documentation d’exploitation et les obligations de conformité restent indispensables.

Peut-on travailler en agile avec un contrat ?

Oui, et c’est même préférable. La valeur vise la négociation contractuelle utilisée comme arme, pas l’existence d’un contrat. La difficulté vient du forfait qui fige à la fois une liste de fonctionnalités et une date : il rend l’adaptation impossible autrement que par avenant.