L'illusion du pilotage de projet agile : sur le papier seulement?

Je ne compte plus les fois où j'ai entendu dire : « Nous, on est passés à l'agile. » Pourtant, quand on creuse un peu, on découvre souvent une réalité bien différente. Derrière les post-it colorés, les réunions quotidiennes et les tableaux Kanban flambant neufs, beaucoup de projets ne sont pas agiles — ils jouent à l'être. Et cette illusion du pilotage agile, je la vois se répéter, encore et encore, dans les entreprises, petites ou grandes, publiques ou privées.

En tant qu'expert en intégration de solution IT, j'ai eu la chance (ou parfois la malchance) d'observer l'agilité sous toutes ses formes. Sur le papier, tout semble parfait : sprints bien découpés, backlog priorisé, démos de fin d'itération, rétrospectives enthousiastes.

Je vous partage ma réflexion sur l'illusion du pilotage de projet agile

Mais dans les faits, les décisions se prennent encore en haut lieu, la planification reste rigide, et les équipes n'ont que peu de marge de manœuvre. L'agilité devient un vernis, une manière de rendre un projet plus "tendance", sans jamais en adopter les vrais principes.

L'agilité, à la base, n'est pas une méthode miracle, mais un état d'esprit : celui de l'adaptation continue, de la collaboration et de la remise en question. Pourtant, combien d'organisations confondent vitesse et agilité ? Elles pensent qu'en raccourcissant les cycles, en multipliant les livrables, elles seront plus efficaces. Mais si le produit livré ne répond pas mieux aux besoins, où est la valeur ajoutée ?

J'ai accompagné des équipes dans le déploiement d'un ERP connu, censé être piloté en mode agile. Les dirigeants voulaient "sortir de la lourdeur du cycle en V" et promettaient plus de flexibilité. Mais au premier retard, tout est redevenu comme avant : comité de pilotage, jalons figés, reporting excessif. L'agilité s'est envolée dès que le risque est apparu. On ne voulait plus apprendre, on voulait contrôler. Et c'est précisément ce qui tue l'agilité : la peur de l'incertitude.

Le vrai problème, selon moi, vient de la confusion entre faire agile et être agile. Faire agile, c'est adopter des outils comme Monday l'outil ou Jira, organiser des stand-up meetings et afficher de beaux indicateurs. Être agile, c'est accepter de ne pas tout maîtriser, de donner du pouvoir aux équipes, et de laisser le client influencer la trajectoire du projet. Dans la plupart des entreprises, on adopte les rituels sans changer la culture. Résultat : on a des équipes frustrées, des sponsors sceptiques, et des projets qui avancent à deux vitesses — la vitesse affichée et la vitesse réelle.

Quand on doit piloter un projet de transformation numérique, notamment un ERP, la tentation est grande de vouloir "industrialiser l'agilité". On parle de "SAFe", de "Scrum à l'échelle", de "gouvernance agile". Et je l'ai moi-même fait, en tant que chef de projet ERP. Mais soyons honnêtes : quand on commence à rédiger des procédures pour être agiles, on a déjà perdu une partie de l'esprit. L'agilité, ce n'est pas un mode d'emploi, c'est une posture collective.

Dans certains projets, notamment d'ERP ou de logiciel TMS, l'illusion est encore plus forte. On prétend être agiles parce qu'on fait des itérations, mais la réalité, c'est qu'un ERP ne se construit pas comme une application mobile. Il repose sur des processus structurants, une logique d'intégration, une architecture complexe. L'agilité peut y trouver sa place, mais elle doit s'adapter à la nature du projet, pas l'inverse. J'ai vu des équipes tenter de "scrumer" des paramétrages d'ERP comme s'il s'agissait de développement pur, et finir épuisées, perdues dans des tâches trop dépendantes les unes des autres.

Et puis, il y a les sponsors qui veulent tout et tout de suite. Ils réclament de la visibilité, des livrables fréquents, mais sans accepter la part d'imprévu. Ils veulent un résultat "agile", mais un budget et un planning "classiques". L'illusion du pilotage agile naît souvent là : on parle d'itérations, mais on pense toujours en jalons. On parle de collaboration, mais on exige de la conformité.

Pour autant, je ne suis pas pessimiste. L'agilité, quand elle est bien comprise, transforme profondément la manière de concevoir les projets. Elle redonne du sens, elle libère les talents, elle accélère l'apprentissage collectif. Je l'ai vue fonctionner dans certaines entreprises, notamment celles qui ont su l'intégrer dès le cadrage du projet, avec des équipes mixtes métier-IT, un vrai partage de responsabilité, et une transparence totale.

Prenons un exemple concret : un projet d'ERP expert dans une entreprise industrielle. Le DSI et la direction métier ont décidé de bâtir la roadmap autour d'objectifs fonctionnels, non techniques. Les utilisateurs finaux participaient à la priorisation. Les sprints étaient ajustés selon la valeur métier réelle, et non en fonction du plan initial. Les réunions de sprint review servaient à apprendre, pas à justifier. Le projet n'a pas été parfait, mais il a évolué au bon rythme, sans rupture ni guerre d'ego. Voilà ce que j'appelle une vraie agilité : une organisation qui apprend en marchant.

Le plus grand danger, c'est de croire que l'agilité est une garantie de succès. Ce n'est pas le cas. L'agilité n'est pas une religion, mais un cadre de travail qui ne fonctionne que si chacun en comprend les règles du jeu. Dans beaucoup d'entreprises, on a voulu être agiles pour être modernes, pas pour être meilleurs. Et c'est là que l'illusion s'installe : on met des mots nouveaux sur des pratiques anciennes.

Je reste convaincu que l'avenir des projets IT passera par une hybridation : un mélange de rigueur et de flexibilité, de gouvernance et d'autonomie. Les outils évolueront, les méthodes aussi, mais le fond restera le même : comprendre les besoins, écouter les utilisateurs, livrer de la valeur, et apprendre de ses erreurs.

La prochaine fois qu'on me dira "on fait de l'agile", je poserai simplement une question : "Et qu'avez-vous appris de vos derniers sprints ?". Parce que l'agilité, la vraie, ne se mesure pas au nombre de post-it, mais à la capacité d'une équipe à progresser, ensemble, dans l'incertitude.

Outre l'email / téléphone, les visioconférences sur Google Meet sont une moyen privilégié de me contacter. La simplicité d'utilisation de cet outil en fait un choix évident, n'imposant aucune installation. Renseignez mon adresse email pour une invitation via Google Agenda.

Pays de Provence, le 6 octobre 2025

Michel Campillo
Consultant chef de projet IT
☎ 06 89 56 58 18  ✉ contact par email, voir plus bas

➽ Les articles d'actualité sur les problématiques d'entreprise sont repris chronologiquement sur la page d'accueil du blog. J'aime cet article sur les ERP: « Lettre de motivation du consultant fonctionnel ERP ».

Ce billet vous a intéressé? Alors partagez-le en cliquant sur les boutons ci-dessous:

Merci de vos partages! 👷🏻‍



🎯 À consulter : Mentions légales. Derniers articles : Openbravo, Implémentation d'un logiciel : les différentes phases, Plushtodon, un éléphant en peluche résume les paradoxes de Mastodon, Le pilotage de projet ERP, 3 règles de mise en œuvre, La reprise de données, étape importante d'un projet ERP, Sécurité informatique pour les néophytes : protégez vos données, Page entreprise sur Linkedin, pour quoi faire ?, Processus d'achat et approvisionnement, les différentes étapes, Outils de gestion de projet Agile, panorama et alternatives, Leçons tirées de la transformation numérique dans les entreprises, Ma playlist du moment, Repenser l'architecture logicielle, l'art de la transformation numérique, Quand les logiciels se parlent : le rôle clé des API, Le meilleur logiciel ERP n'est pas le même pour vous et pour moi, La prime de chantier dans le BTP, levier de motivation et de performance, x, x, x.
⛅ L'automne est arrivé, un temps propice au travail non? ☂️

Copyright © 2004-2025 Michel Campillo, tous droits réservés