Fondements
Lire le Manifeste de près
Le Manifeste agile tient sur une demi-page : une phrase d'ouverture, quatre comparaisons et une phrase de conclusion. Beaucoup de ceux qui l'invoquent ne l'ont jamais lu, et on lui prête des idées qu'il ne contient pas, comme le refus de la documentation ou des plans. Cet article le lit ligne à ligne, dans sa traduction française officielle.
Un texte plus souvent cité que lu
La scène est banale. En réunion, quelqu'un demande où se trouve la documentation d'une fonction livrée le mois précédent. Un collègue répond : « On est en agile, on ne documente pas. » Un autre jour, une directrice demande une date de livraison et s'entend dire que « l'agile, c'est sans planning ». Dans les deux cas, la personne croit citer le Manifeste, et elle lui fait dire le contraire de ce qu'il dit.
Le texte proprement dit compte moins de quatre-vingts mots en français. Il porte un titre, Manifeste pour le développement Agile de logiciels, et il est suivi de dix-sept signatures et d'une notice qui autorise à le reproduire à condition de le reproduire en entier. Nous le citons ici par fragments pour les commenter, et le texte intégral figure dans la base documentaire avec ses douze principes.
La phrase d'ouverture
Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :
Manifeste pour le développement Agile de logiciels (2001), texte intégral
Chaque élément de cette phrase mérite qu'on s'y arrête.
« Nous » désigne les dix-sept signataires. Ils parlent en leur nom et rapportent leur expérience. Cette première partie du texte ne prend la forme ni d'une norme ni d'un règlement, même si les principes qui la suivent emploient volontiers l'impératif.
« découvrons » est au présent. L'original anglais, « We are uncovering », emploie une forme qui insiste sur une action en cours. Dans l'article où ils présentent le Manifeste en août 2001, Martin Fowler et Jim Highsmith expliquent que ce verbe a été choisi pour signaler que les signataires n'ont pas toutes les réponses et qu'ils ne croient pas aux solutions miracles. Le texte se présente donc comme un état provisoire de leurs connaissances.
« par la pratique et en aidant les autres à le faire » indique d'où vient ce savoir. Les signataires développaient des logiciels et conseillaient des équipes, et c'est de ce travail qu'ils tirent leurs conclusions. Cette origine fait la force du texte, parce qu'il vient de gens de métier. Elle en marque aussi la limite : un témoignage de praticiens ne vaut pas une preuve, comme le rappelle l'article Que valent les preuves ?.
« développer des logiciels » fixe le domaine. Le Manifeste parle de logiciel et ne prétend rien dire de l'école, de l'hôpital ou du management. Ceux qui l'appliquent ailleurs le font sous leur propre responsabilité.
« Ces expériences nous ont amenés à valoriser » annonce la nature de ce qui suit. Les quatre lignes suivantes expriment des préférences nées de l'expérience, et non des règles à appliquer mécaniquement.
Quatre comparaisons
Le cœur du texte est une liste de quatre lignes construites de la même façon : un premier élément, les mots « plus que », puis un second élément.
| Ce que les signataires privilégient | Ce dont ils reconnaissent la valeur |
|---|---|
| Les individus et leurs interactions | les processus et les outils |
| Des logiciels opérationnels | une documentation exhaustive |
| La collaboration avec les clients | la négociation contractuelle |
| L’adaptation au changement | le suivi d’un plan |
La phrase qui suit immédiatement donne la clé de lecture :
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Manifeste pour le développement Agile de logiciels (2001)
Chaque ligne compare donc deux choses utiles. Les mots « plus que » traduisent l'anglais « over » et ne signifient pas « à la place de ». Les processus, la documentation, les contrats et les plans gardent leur valeur, et le texte le dit en toutes lettres. Il donne une règle d'arbitrage pour les moments où les deux éléments entrent en conflit et où l'on ne peut pas tout faire.
Les mots de la colonne de droite sont choisis avec soin. La documentation y est qualifiée d'« exhaustive ». Le contrat y apparaît sous la forme de la « négociation contractuelle », c'est-à-dire d'une relation avec le client qui se réduit à discuter des clauses. Le plan y figure à travers « le suivi » qu'on en fait, quand ce suivi devient un but en soi. Dans les trois cas, la critique porte sur l'excès et laisse intacte la chose elle-même.
Les contresens courants
« L'agile, c'est sans documentation »
Le texte reconnaît la valeur de la documentation et critique seulement celle qui se veut exhaustive. Jim Highsmith l'écrit clairement dans l'historique publié sur le site du Manifeste : les signataires acceptent la documentation, mais pas des centaines de pages jamais mises à jour et rarement consultées. L'article Des logiciels opérationnels précise quelle documentation garder.
« L'agile, c'est sans plan »
Highsmith écrit dans le même passage que les signataires planifient, tout en reconnaissant les limites de la planification dans un environnement instable. Les principes parlent d'ailleurs d'« objectifs fixés » et de livraisons à un rythme régulier, ce qui suppose de prévoir. L'article L'adaptation au changement montre que les équipes agiles planifient souvent, par petites touches.
« L'agile, c'est sans processus ni contrat »
Les méthodes défendues par les signataires sont elles-mêmes des processus, avec des étapes et des rôles, et leurs auteurs travaillaient sous contrat avec leurs clients. La première et la troisième valeur demandent seulement que ces cadres restent au service des personnes et de la relation avec le client (voir Les individus et leurs interactions).
« L'agile, c'est aller plus vite »
Le premier principe parle de satisfaire le client « en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ». L'anglais dit « early and continuous delivery » : il s'agit de livrer tôt et sans interruption, et non de travailler à une cadence plus élevée. Un autre principe demande au contraire « un rythme de développement soutenable ». Le Manifeste ne promet nulle part de produire davantage en moins de temps.
« L'agile, c'est Scrum »
Le texte ne nomme aucune méthode. Les mots sprint (une itération de durée fixe), backlog (la liste ordonnée du travail à faire), mêlée quotidienne ou user story (le court récit d'un besoin) n'apparaissent ni dans les valeurs ni dans les principes. Ils viennent de méthodes particulières, Scrum et Extreme Programming, qui existaient avant le Manifeste et que celui-ci ne départage pas.
Une phrase de ce type hors du logiciel
La construction en « plus que » se comprend mieux sur un exemple familier, parce qu'on y voit comment les deux éléments coexistent.
Ce que la traduction française nuance
La version française publiée sur le site officiel a été réalisée par des membres du Club Agile Rhône-Alpes et relue par d'autres praticiens francophones. Elle est fidèle, avec quelques nuances utiles à connaître quand on la compare à l'original.
- « Working software » devient « logiciels opérationnels ». L'anglais dit simplement « un logiciel qui marche ».
- « Responding to change » devient « L’adaptation au changement ». L'anglais parle de répondre au changement, ce qui est un peu plus actif.
- La phrase finale anglaise oppose les éléments « de gauche » et « de droite », selon leur place sur la page. Le français parle des « premiers » et des « seconds éléments ».
- Le quatrième principe commence en anglais par « Business people and developers », c'est-à-dire les gens du métier et les développeurs. Le français écrit « Les utilisateurs ou leurs représentants et les développeurs ».
Ces écarts ne changent pas le sens général. Ils rappellent qu'une discussion précise sur un mot gagne à revenir à l'original.
Limites et pièges
La première limite tient au genre du texte. Une déclaration de valeurs obtient facilement l'adhésion, et elle est difficile à appliquer. Le Manifeste ne dit pas combien de documentation suffit, ni à partir de quand un plan devient un carcan. Il laisse ces jugements à chaque équipe, ce qui permet à des organisations très différentes de s'en réclamer, y compris à tort. L'article Être agile ou faire de l'agile décrit ces dérives.
Le deuxième piège est de traiter le texte comme une écriture sacrée. Il a été rédigé en trois jours par dix-sept consultants et auteurs, pour le logiciel de 2001, et ses auteurs eux-mêmes le présentent comme une découverte en cours. On peut le trouver juste sur un point et insuffisant sur un autre.
Le troisième piège est d'oublier les douze principes. Ils sont moins connus que les quatre valeurs et ils sont plus concrets : ils parlent de cycles de quelques semaines, de travail quotidien avec les utilisateurs, de rythme soutenable et d'excellence technique. Lire les valeurs sans les principes favorise les interprétations vagues.
Il faut enfin rappeler que des valeurs ne se démontrent pas comme des faits. On peut vérifier si une pratique donnée, par exemple les livraisons fréquentes, améliore les résultats. On ne peut pas prouver qu'une préférence est la bonne dans tous les contextes.
Pour aller plus loin
- Snowbird, février 2001 : la naissance du Manifeste : dans quelles circonstances le texte a été écrit.
- Les individus et leurs interactions : la première valeur, et ce qu'elle ne dit pas des outils.
- Des logiciels opérationnels : la deuxième valeur, et la documentation qu'il faut garder.
- L'adaptation au changement : la quatrième valeur, et pourquoi planifier reste nécessaire.
- Être agile ou faire de l'agile : ce qui arrive quand le texte est invoqué sans être lu.
- Le Manifeste agile et ses douze principes : le texte intégral dans sa traduction française officielle.
Sources principales : Manifeste pour le développement agile de logiciels (2001) et ses principes, agilemanifesto.org, texte anglais original et traduction française officielle ; Martin Fowler et Jim Highsmith, « The Agile Manifesto », Software Development (août 2001) ; Jim Highsmith, « History: The Agile Manifesto » (2001), agilemanifesto.org/history.html.