Depuis plusieurs années, dans le cadre de mes activités d’accompagnement des acteurs de projets du SI (système d’information) en entreprise, j’observe une tendance très nette à vouloir prolonger des projets, au-delà de leur date prévisionnelle de fin ou bien même les perpétuer sans aucune fin annoncée, sous couvert de différentes raisons, dont la pertinence peut être discutable.

En effet les SI étant par nature fortement soumis à des évolutions permanentes, soit à cause des inévitables évolutions technologiques, soit à cause des non moins inévitables besoins d’activité, réactivité ou pro-activité de leurs utilisateurs et propriétaires, on se dit que, finalement, un projet informatique ne saurait avoir de fin, puisque ce travail d’enrichissement ou d’adaptation ne sera jamais terminé et toujours sujet à de nouvelles sollicitations de l’environnement extérieur ou déclenché par des besoins internes.

Evidemment, il en résulte des projets qui peinent à respecter leurs budgets puisque le temps n’est pas compté, en échéance flottante, ou, pire encore, qui ne parviennent pas à respecter leurs intentions et objectifs puisque, de jour en jour, les besoins des demandeurs changent, alors on s’adapte, on adapte, on défait ce qu’on a fait hier… Bref on pourrait les appeler des « projets Pénélope », après avoir connu l’ère des projets Titanic ! Tout cela crée parfois beaucoup de surcoûts incontestables et peu de valeur ajoutée réellement constatable.

Et cette idée d’adaptation permanente nous conduit à évoquer l’influence des effets de mode dont l’un des plus marquants de notre décennie est l’agilité … concept largement répandu et revendiqué de nos jours, avec une certaine légitimité : qui n’est pas ou ne voudrait pas être agile au maximum de ses possibilités ? Miroir aux alouettes ou seule voie de survie, la question est posée.

On peut comparer ce raz-de-marée à l’influence du redoutable concept d’efficacité, qui faisait rage dans les années quatre vingt-dix, en France, en Europe et dans le monde… De nos jours même on pourrait dire que l’efficacité a endossé la parure de l’agilité pour revenir sur le devant de la scène : en ces temps difficiles où tous les acteurs économiques mondiaux peinent à améliorer sereinement leurs performances en sauvegardant leur relation aux autres sur un « océan bleu », on se doit d’être agile pour s’adapter au maximum aux vents changeants, tel un frêle esquif sur les vagues tumultueuses d’un monde toujours un peu plus fou… !

Alors, après réflexion, au nom de la noble cause d'agilité faut-il réformer le mode projet ou bien s'y conformer ? Le fait est que les tenants de l'agilité (mal comprise) prônent des "projets sans fin" pour adapter (par obligation, réactivité...) les SI en permanence ; ce qui dénature le travail par projet, puisque par définition académique admise de longue date (même au temps des pharaons égyptiens, les projets de pyramides devaient se terminer un jour et si possible avant la mort du pharaon !) un projet se doit d’avoir un début et une fin.

Entendons-nous bien : au-delà de la définition académique, l’obligation de fin d’un projet est salutaire, pour en constater la production effective et donc la performance obtenue, en temps et budget limités et convenus, dans une logique d’engagement réciproque au service de l’intérêt de tous, demandeurs et répondeurs. Elle est salutaire également pour les humains qui participent aux projets ; en effet le projet étant une façon particulière de travailler, par effort, souvent intense et sous tension croissante, les limites de la capacité humaine, intellectuelle et émotionnelle, imposent une pause formelle à la fin d’un projet, sans quoi la personne peut se mettre en danger en dépassant sans cesse ses limites ; c’est ce qui peut se passer plus probablement dans des projets sans fin.

Prenons un exemple simple : pourrions-nous imaginer un événement tel que la phase finale de la coupe du monde de football se dérouler à échéance flottante ? Bien qu’il y ait eu des événements préparatoires et éliminatoires, cette phase finale se déroule en temps limité, disons un mois calendaire environ, et se termine par un résultat simple et binaire : repartir chez soi en emportant la coupe pour quatre années ou pas.

Pour en revenir à l’agilité, le but ici n’étant pas d’en rappeler la définition et la vertu, on peut aisément constater que certains (dirigeants, pilotes et autres managers) y ont vu une opportunité pour faire travailler en continu les acteurs des SI, techniciens spécialisés d’une discipline qui étend son emprise un peu plus chaque jour sur tous les domaines de la vie ordinaire des terriens. Ce travail au fil de l’eau nous éloigne d’un projet vu comme un système de production exceptionnel et temporaire, au profit d’un système de production établi et inscrit dans l’infini du quotidien répétitif. S’agissant des projets, dont l’incertitude demeure un caractère majeur, puisque justement le projet est un système de production non stabilisé, ce mode de travail s’apparente à ce qu’on appelle parfois le mode pompier, caricature d’un monde où l’on « passe son temps » à éteindre des incendies, ce qui, certes, est valeureux et valorisant, mais pour autant, n’est pas un exemple indiscutable de création et d’innovation, organisé et optimisé.

Or la vraie question est de savoir si les SI sont suffisamment évolutifs pour supporter des « déformations en continu » et permettre de rester conforme au travail par projet, ce qui signifie savoir s'arrêter. L'expression n'est pas de moi et n'est pas nouvelle, elle avait été inventée par le Directeur des systèmes d’information de France Télécom, à l’époque héroïque de l’ouverture à la concurrence de la téléphonie fixe, il y a vingt ans de cela, ce qui en soi constituait une révolution dans la maison monopolistique issue des P & T d’après-guerre.

Soyons clair : si cela avait été le cas, tout aurait été plus facile depuis cette époque ; mais il faut bien admettre que, constitués par accumulation de couches successives comme un immense patchwork dans beaucoup d’entreprises anciennes, qui furent souvent des pionnières dans l’informatisation de leurs métiers, beaucoup de SI sont tout sauf flexibles, ce qui fait que les projets cassent l'existant autant qu'ils introduisent des évolutions, c’est pourquoi ils s'enlisent, en tentant parfois de réparer l’irréparable ; et donc ils ne se terminent pas et ce faisant, ils risquent d’être abandonnés un jour sans avoir atteint leur objectif ni produit la moindre valeur (voir le « chaos report » du Standish Group). On a donc voulu compenser ce manque de flexibilité des SI par l'agilité des esprits et des comportements, ce qui peut aider mais ne saurait suffire... les meilleurs ouvriers du monde ne pouvant par la seule force de leur compétence compenser la mauvaise qualité des briques et du ciment de ces constructions hétérogènes voire hétéroclites.

Pour « limiter la casse » justement, je dirais que ma préférence reste donc au projet borné dans le temps, le plus court possible, pour être en mode « sprint », tendu vers un objectif visible qui ne sera pas remis en question (c’est le fléau des projets, on le sait) et pour lequel on abaissera le drapeau à damiers au moment du franchissement de la ligne d’arrivée et du décompte des résultats atteints.

En résumé, pourquoi se conformer ?

Parce que, sauf cas extraordinaire, il y a beaucoup à gagner en se conformant aux « invariants » du travail par projet : meilleure visibilité du résultat atteint, point d’arrêt formel avant de redémarrer pour autre chose, régénération des capacités de motivation et d’endurance des acteurs … En tout cas, il faut dire, selon moi, que si l’on ne finit pas un projet, que ce soit par choix décidé ou par impossibilité concertée, alors tout simplement ce n’est plus un projet car un projet se doit d’avoir un début et une fin, un point c’est tout. Soit, objectera-t-on peut-être et alors, la belle affaire ? Ce qui importe ce n’est pas de respecter de sacro-saints objets de culte savamment bâtis de longue date ; ce qui importe ce sont les résultats qu’on obtient et donc qu’importe le projet pourvu qu’on ait le résultat ! Oui mais… ce n’est pas en reportant éternellement l’échéance initiale d’un projet qu’on obtient de meilleurs résultats ; bien au contraire le plus souvent, d’une part la dynamique s’essouffle et d’autre part l’objectif devenant plus diffus, parce que plus éloigné « artificiellement », on le perçoit moins bien et on ne sait plus ce qu’il faut faire exactement et c’est alors qu’on régresse, à vouloir trop bien faire…

Et s’il faut réformer… ?

Très bien, si l’on admet que le travail par projet au sens « ancien » du terme est devenu une forme périmée de production ; mais alors il faut aller au bout du raisonnement, c’est-à-dire formaliser et conceptualiser un nouveau mode de travail et de production, sans se contenter de le qualifier de projet agile ou autre production basée sur une incrémentation permanente et infinie…

Il y aurait donc un effort de réforme, au vrai sens profond du terme, voire de révolution, à mener pour aboutir à autre chose ; et quelle autre chose ? Et qui ferait cet effort ? Pour quel bénéfice en retour ?

Pierre Yves Dumant