« Qui de vous en effet, s’il veut bâtir une tour, ne commence par s’asseoir pour calculer la dépense et voir s’il a de quoi aller jusqu’au bout ? De peur que, s’il pose les fondations et ne peut achever, tous ceux qui le verront ne se mettent à se moquer de lui, en disant : « Voilà un homme qui a commencé de bâtir, et il n’a pas pu achever ! » » Luc 14,28
Apprendre à gérer un projet, alors que tous les projets sont différents en termes de conditions, de ressources, d’exigences, de nature. Qu’y-a-t-il de commun qu’on puisse appréhender dans la théorie, pour se donner un maximum de chances de mener à bien les projets qui nous sont confiés, de la manière la plus durable c’est-à-dire sans épuiser les ressources humaines, financières, matérielles, nécessaires, ni impacter (trop) négativement l’environnement – voire permettre à ces ressources et à cet environnement de se régénérer et potentiellement d’acquérir de l’expérience pour participer à la réalisation d’autres projets ? Rien de commun. Rien non plus entre les projets, et les arbres. A priori.
Pourtant, gérer un projet, cela s’enseigne :
- On transmet l’importance du « cadrage projet », cette phase pendant laquelle est réalisé un bilan des forces et richesses disponibles, pour voir si ces données d’entrée sont compatibles avec l’ambition du projet. Le paramètre temps est central, puisque l’ambition s’exprime aussi en termes de délai, et qu’il est souhaitable, lors de cette phase, de planifier l’organisation, l’utilisation des différentes ressources pour vérifier que chaque ressource ne soit pas affectée en double. Le temps lui-même peut être considéré comme une ressource.
- Le vocabulaire de la construction a été largement repris dans la gestion de projet informatique :
- notion de maîtrise d’ouvrage, « MOA » : les commanditaires ou leurs représentants, assistés éventuellement d’une « AMOA » = assistance à maîtrise d’ouvrage
- notion de maîtrise d’œuvre, « MOE » ou « MO » : ceux qui réalisent, des architectes aux maçons
- notion de cahier des charges / spécifications : le document de dialogue entre MOA et MOE, dans lequel doivent être détaillées les différences exigences et contraintes du projet
- on parle même d’architecture IT, d’urbanisation du système d’information,…

En gestion de projet numérique, en apprend qu’historiquement, en effet, le domaine de la construction a inspiré le vocabulaire et la méthodologie employés. Cependant, serait-ce par la nature plus « flexible » du développement informatique, par le fait que des contraintes comme la gravité ou la stérie (contrainte relative à la place qu’occupent dans l’espace les différents éléments) ne s’appliquent pas, et/ou parce que les développeurs, ces « ouvriers du code », sont plus qualifiés que les ouvriers du bâtiment, moins enclins à être de simples exécutants des actions traduisant le plan de l’architecte, plus intéressé d’avoir accès à une vision d’ensemble ? De nouveaux modes projets se sont mis en place. Plutôt que de planifier tout à l’avance, et de risquer de finir avec une « usine à gaz » qui ne soit pas utilisée, le numérique donnait la possibilité de travailler par itération, c’est-à-dire de proposer aux commanditaires et aux utilisateurs des versions intermédiaires du logiciel / de l’application / du module, donc de rapprocher MOA et MOE. Fini le cahier des charges : en s’hybridant avec la méthodologie kanban issue de l’industrie japonaise, les équipes désormais dénommées « agiles » se sont dotées de référentiels opératoires permettant de prioriser les fonctionnalités à développer, et de suivre leur avancement. Un fonctionnement presque idéal, sans hiérarchie formelle mais, dans des équipes de moins de 10 personnes, un « Product Owner », redevable de l’obligation de résultat, et un « Scrum Master », redevable de l’obligation de moyen, dans la méthodologie dite « Scrum » – comme la mêlée au rugby, une belle image de l’esprit d’équipe et de la sportivité/performance professionnelle qui est de mise dans ce contexte.

En fait, pendant mes années d’expérience professionnelle en tant que salariée dans des équipes numériques, je n’ai jamais vu appliquée à 100% cette méthodologie scrum ou agile. Et en en parlant autour de moi, cela semble assez rare hors d’entreprises dédiées (ESN multi-projets). Ou plutôt : on dit qu’on fait ou qu’on veut faire, mais on tombe dans certains écueils, notamment en termes de gouvernance : centralisation de l’information et de la vision d’ensemble du projet, daily meeting hebdomadaires qui font plus de 90 minutes, clients utilisateurs ayant très peu de temps à dédier au projet donc pas de revue de sprint, très peu de tests intermédiaires.
Prétendre faire de l’agile sans suivre la méthodologie projet, nécessite une reprise de la verticalité par le chef de projet pour que finalement quelque chose avance un peu, sous son impulsion. Ce qu’on peut garder alors, c’est le kanban, mais le reste ressemble beaucoup à la méthodologie plus classique (dite « cycle en V » car le projet est décomposé en tâches et sous-tâches tandis qu’on traduit les besoins plus profondément dans le concret. Entretenir la méthodologie agile dans l’organisation nécessite de la cultiver. C’est une des redevabilités du scrum master, l’obligation de moyen, en l’occurrence, le moyen en question est en particulier le cadre méthodologique. Beaucoup d’équipes projet naviguent de fait entre ces deux pôles, l’un bâti sur une organisation projet très verticale – le « cycle e V » – l’autre assez horizontale – l’agile / le scrum.


Savoir gérer les projets signifie bien connaître ces deux méthodologies et savoir choisir, pour un projet donné, quel cadre méthodologique il vaut mieux adopter, de façon consciente et sans opérer les « glissements » qui font qu’on ne respecte pas ce qu’on affiche, et que le cadre devient opaque, les règles du jeu « changeantes » pour les équipiers, ce qui est assez frustrant et démotivant. Des éléments pour choisir le bon cadre méthodologique seront proposés dans les paragraphes suivants.
Avant cela, je voudrais raconter comment cette compréhension fine des méthodes projet est survenues dans le même temps que je conduisais des recherches sur les questions de gouvernance et de faire ensemble, en prenant en compte notamment les apports de l’Université du Nous, collectif expérimentateur d’un partage de gouvernance en acte et relais de recherches notamment en sociologie. Ces recherches répondaient à une aspiration personnelle, une quête pour comprendre pourquoi l’autorité, qui requiert que les personnes sur lesquelles on l’exerce abdiquent une partie au moins de leur liberté, était souvent nécessaire, comment l’exercer de façon respectueuse des personnes et comment la recevoir sans, quelque part, se renier. J’ai compris que pour s’organiser ensemble, il faut bien s’appuyer sur une vision partagée. Que dessiner les contours de cette vision est rarement le fait d’un grand groupe, plutôt d’une personne seule ou d’un tout petit noyau. C’est comme écrire un livre à plusieurs : ce serait un peu illusoire, cela manquerait de cohérence. On peut imaginer un recueil de nouvelles, mais pas vraiment ce qu’on appelle une « œuvre ».
Donc cette personne, appelons-la l’entrepreneur, envisage de mettre en place quelque chose qui n’existe pas. Il peut avoir différentes inspirations – c’est presque spirituel – il « voit » ce à quoi cela peut ressembler, et il se rend compte qu’il ne peut réaliser cela seul. IL y a une théorie qui nomme cette personne la « source ». Comme cette idée l’habite, il en parle autour de lui et cette idée peut entrer en résonance avec les aspirations d’autres personnes, qui proposent leur aide. Ou bien, l’entrepreneur a les moyens de rémunérer des personnes pour l’aider dans son projet. Dans les deux cas, il peut se comporter en « chef » et prescrire aux autres ce qu’ils doivent faire pour l’aider. Si des niveaux de décision intermédiaires sont mis en place, cela peut conduire à une organisation dite « pyramidale », qui est en fait classique dans le monde économique. C’est une culture de verticalité. L’entrepreneur peut aussi vouloir s’associer autrement. Il se dit que d’autres peuvent également avoir de supers idées sur ce à quoi le projet pourrait ressembler. Les personnes s’associent et prennent l’habitude de partager l’objet de l’association : on parle souvent de « projet associatif » qu’il est nécessaire de formuler. Les choses sont décidées ensemble, une culture d’horizontalité, où chacun a voix au chapitre, s’instaure. Il y a une façon « extrême » de concevoir l’horizontalité : c’est la stigmergie. À partir d’un but commun, qui peut être implicite, tous les individus du groupe peuvent identifier une action à faire pour contribuer, et en laisser trace pour que d’autres prennent le relais. Force est de constater que, chez les humains, les conditions nécessaires pour que tous se mettent en ordre de marche sans l’impulsion d’une « source » sont rare.
Là encore, verticalité et horizontalité sont deux polarités qu’on pourrait considérer incompatibles. J’ai compris qu’une fois que l’existence de ces deux polarités a été posée, on peut prendre de la hauteur pour les utiliser dans la formation de façon harmonieuse, les articuler, en faisant vivre, justement, la culture de l’acceptation de ces deux modes, verticalité et horizontalité, sans « jugement de valeur ». J’ai également compris que « faire ensemble » n’est pas évident, est « coûteux » en temps, et fait énormément travailler les « égos » de chacun – si du moins il s’agit d’un vrai travail ensemble, et non d’abdiquer son pouvoir à une personne charismatique, un « gourou ». Une des personnes qui me l’a mieux fait comprendre est Serge Levan, qui intervenait dans un module que j’ai suivi en formation continue à l’Université Technologique de Troyes. Il faut donc :
- d’une part monter en compétences pour que ce faire-ensemble soit moins coûteux
- d’autre part ajuster les temps de faire ensemble selon la possibilité, notamment le fait d’en avoir le temps, et selon la nécessité :
- besoin d’impliquer les personnes,
- enjeux, et/ou
- besoin de bénéficier de l’intelligence collective (cf par exemple cet article de Mehdi Moussaid)
Le temps est un paramètre central : discuter puis décider nécessite d’ouvrir une parenthèse, de créer un espace au sens propre et figuré où les participants à la décision puissent se poser, s’exprimer et écouter. En gouvernance partagée, on évoque la notion de cercle, qui est la figure pour laquelle tous les points sont à équidistance du centre. Cette équité de départ est une condition pour que chacun/chacune puisse se sentir participer « à égalité » avec tous les autres. Avez-vous déjà eu à déplacer quelque chose de très lourd, par exemple à l’occasion d’un déménagement, en se rendant compte que chacun avait envisagé la procédure différemment ? Dans l’effort, c’est très compliqué de s’expliquer, donc soit quelqu’un a un ascendant (un « lead ») naturel, et est suivi, soit ça peut vite être la cacophonie. Dans ce cas il faut poser le meuble, se parler pour ajuster les actions à réaliser. Autre exemple : le concert d’orchestre. Lors de l’exécution d’un morceau, on ne peut pas s’arrêter pour décider ensemble de l’intention à mettre au prochain mouvement, de l’interprétation : il n’y a pas cet espace, et pour que l’œuvre soit interprétée avec une intention cohérente, un « chef d’orchestre » est nécessaire. Mais il est tout-à-fait possible, avant un concert, que les musiciens puissent participer à des décisions sur l’interprétation, ou même sur le programme. Cela étant, j’ai rarement vu des orchestres où ces décisions sont collectives. Peut-être une trop grande culture de verticalité ? Comme dans l’armée. Comme chez les pompiers. Dans l’urgence, on ressent le besoin d’un chef assertif et réactif.

Assez naturellement, ce sont les projets de type associatif au sens qu’ils impliquent une association libre des personnes, de culture plus horizontale, qui sont les plus enclines à permettre la montée en compétence du groupe vers le « faire ensemble ». D’une part cela n’implique pas, on l’a vu, que l’ensemble du projet soit conçu ainsi : c’est même le plus souvent des individus qui sont à l’origine, qui sont « sources » de la dynamique. D’autre part, si cette horizontalité devient une valeur en elle-même, le groupe, notamment par peur qu’une logique de « chef » s’installe, peut se priver de la dimension verticale dont on a vu qu’elle est incontournable en situation d’urgence. Ces mêmes organisations, associations, syndicats,… peuvent être jugés très sévèrement par les personnes habituées aux organisations plus verticales qui dénoncent l’inefficacité, la lourdeur d’un système horizontal. L’horizontalité sans cadre peut effectivement tourner à l’immobilisme. Les méthodes agiles, qui introduisent comme nous l’avons vu une certaine horizontalité, s’appuient sur un cadre très explicite : durée des itérations, rôle des équipiers,… En gouvernance partagée, une pratique courante consiste à nommer dans chaque réunion un facilitateur, qu est garant du cadre des échanges. Il ne s’agit pas uniquement de veiller à ce que les échanges soient cordiaux, mais aussi d’orchestrer les échanges au service de la tâche que le groupe doit effectuer. Une autre règle qui est donnée, est que la personne qui est responsable de l’accomplissement de cette tâche ne peut être facilitateur. Ici, c’est la responsabilité sur le contenu qu’on sépare de la responsabilité sur le contenant. Cette pratique est un exemple intéressant d’une articulation entre horizontalité (partage des tâches, responsabilités tournantes) et verticalité (présence d’un facilitateur, cadre, rôle « lead » d’un groupe / d’un cercle). Revenons un instant aux projets numériques : en tenant compte des conclusions précédentes, il semble naturel que le mode « cycle en « v » » doive s’appliquer à des projets plus structurants ou au cœur structurant d’un projet, alors que l’agile est plus adapté à un travail à partir d’un framework existant, à du paramétrage, à du développement d’un outil en nocode,… Le monde Unix/Linux est peut-être celui du libre, mais le noyau Linux a été développé avec une équipe très verticale – il paraît que M. Torvalds avait des côtés un peu tyran avec le titre de « dictateur bienveillant »…
Que ce soit pour construire une tour, envisager les prochaines vacances ou décider du repas du soir, tout est potentiellement projet. Sauf, peut-être, les actions quotidiennes, les routines : se laver, faire le ménage, faire un travail répétitif. Et qu’en est-il des modifications opérées par des individus non humains – animaux ou plantes – dans leur environnement ? Par exemple : le peuplement d’un espace par une essence d’arbre, qui en fait une forêt ? Peut-on parler de projet ? De projets du vivant ? À mon sens oui, même si on ne peut pas parler d’intentionnalité. On peut envisager la croissance d’un arbre comme un projet, qui suit ce qu’on appelle un « plan de développement ». Le botaniste Francis Hallé en parle avec talent. Parmi les arbres, il distingue :
- les conifères, qui ont un plan de développement très « centralisé », autour d’un axe structurant sans adaptation possible : si cet axe est coupé, l’arbre est condamné à court/moyen terme
- les feuillus, dont les branches maîtresses sont en général des « réitérations » indépendantes les unes des autres. Il n’y a pas nécessairement d’axe central. S’il y en a un, sa perte – par exemple à cause de la foudre – n’entraîne pas la mort du végétal.
On peut propose que le conifère, avec son axe vertical structurant, modélise en quelque sorte le « cycle en V ». À noter que dans la nature, les conifères sont les arbres les plus adaptés à des conditions contraignantes, dans des conditions de sécheresse, ou en montagne. Les feuillus pourraient, eux, représenter les projets agiles. La structure de base fait l’objet de réitérations. Pas de hiérarchie entre les branches maîtresses, ce qui traduit une certaine horizontalité. Le port de ces arbres est beaucoup plus diversifié que celui des conifères.

Je tire deux conclusions de cette analogie :
- Il y a de la place dans la nature pour conifères et feuillus, et dans chaque catégorie pour une grande variété de plans de développement. Il y a de la place pour différents modes projet, mais comme on reconnaît un arbre à ses fruits, les aboutissements du projet sont conditionnés à la méthodologie choisie. Il apparaît que le choix de la méthodologie est un incontournable du cadrage projet. Qu’une méthodologie claire et non « glissante » permet de clarifier les règles du jeu pour tous, condition nécessaire à la bonne réalisation du projet.
- Les feuillus ont en règle générale deux phases de développement : Une première pendant laquelle le développement est assez centralisé autour d’un axe. Dans cette phase se constitue le bois de cœur. Une seconde où se met en place le port « arborescent » et où on commence à distinguer les branches maîtresses. Le tronc croît en diamètre, et chaque année est repérable à une cerne. Ce phasage est nécessaire pour que l’arbre ressemble à un arbre, et non à un arbuste/un buisson. Dans les projets, on peut aussi imaginer une première phase, autour du porteur de projet – l’entrepreneur mentionné plus haut – puis une seconde qui, tut en restant assez fidèle au projet de départ, peut explorer des possibilités plus large. J’ai en tête aussi l’itération 0 des projets agile/scrum, un peu différente des autres, plus longue, sans revue de sprint, sans livrable. Des adaptations de la méthodologie sont envisageable en cours de projet, si elles sont explicitent et cohérentes.
Laissons-nous inspirer par le vivant. Je parle de biomimétisme – non dans une perspective d’invention des artefacts très techniques qui tentent de reproduire les capacités spectaculaires de certains animaux ou végétaux : se déplacer sur un mur vertical à l’aide de dispositifs puissamment adhésifs, dépolluer un cours d’eau par un métabolisme très spécifique, percevoir des objets dans le noir en émettant des ultrasons,… – mais plus globalement, en nous acculturant à leur capacité à simplement être, les uns avec les autres, à nous supporter, à participer au cycle de la vie, et parfois créer une beauté surprenante et gratuite. Les partis pris et jugements de valeur : horizontalité vs verticalité, nouvel ordre vs ancien ordre, efficacité vs esthétisme, …., gauche vs droite (!), ne sont plus de mise. Tout est à penser dans une grande adaptabilité à des conditions qui seront constamment changeantes. Et il me semble que ce qu’on doit cultiver le plus, c’est l’humilité, et le lien entre les individus, voire au sein de « groupes » agissants.
En ce début d’année 2026, je vous souhaite des projets résilients/robustes, et régénérants.
Superbe et enthousiasmant article mais qui requiert attention, concentration, relecture et synapses fonctionnelles. 👏👏👏