L’AGILITÉ POUR LES PROJETS INDUSTRIELS : COMMENT EN TIRER LE MEILLEUR

“Le management agile est défini comme une organisation de type humaniste, basée sur la motivation des ressources humaines de l’entreprise. Le principe est de remettre l’humain au cœur de l’entreprise.”

I

Quiconque a travaillé dans une entité aux process bien décrits et appliqués a été séduit par l’intelligence méthodique de l’entité et la maîtrise raisonnablement attendue des activités cartographiées.

Pour peu, cependant, que le projet soit un peu hors des chantiers battus, on voit vite la lourdeur induite et l’énergie perdue, dans une entité qui tourne en rond, ou plutôt qui ne tourne plus rond, dans une forêt de procédures derrière lesquelles nombre de collaborateurs déconnectés vont se réfugier.

La solution, c’est l’agilité ou encore le management agile : brisons le carcan : plutôt les hommes bien câblés que le process ; plutôt une bonne relation client qu’on va satisfaire par étape que des allers-retours formels. Allons à l’essentiel, à l’efficace. On y va tous et rendez-vous dans 3 semaines.

Issue du logiciel et des métiers de l’informatique, l’agilité ou encore le management agile est une alternative aux développements séquentiels nécessitant dès le début un cahier des charges abouti, presque figé, et induisant un effet tunnel hors de contrôle.

Las ! Après quelques années de cette innovation enthousiasmante, le bilan est sans appel : ça ne marche pas !

L’objet de cette lettre est d’analyser les raisons de ces échecs répétés et proposer des axes permettant de mettre un peu de flexibilité dans les projets sans mettre en péril leurs réussites.

Les conditions de succès de l’agilité sont avant tout un état d’esprit ouvert, une bonne communication interne (proximité) et externe vers le client, un partage judicieux des objectifs, une organisation associée et, le plus souvent des outils adaptés. Ainsi, lorsque le besoin va s’affiner au fur et à mesure, pour une démarche où on converge vers un produit avec le client, cette démarche est certainement pertinente. C’est le cas pour les phases de développement préliminaire, le premier jet, le prototype par exemple, où le tâtonnement, frère jumeau de la créativité, permet de progresser. Cela marche aussi, dans certains cas pour le, ou plutôt du, logiciel. La performance est souvent au rendez-vous.

II

Des conditions de succès énoncées ci-dessus, on devine aisément les raisons de l’échec : une mauvaise communication, un client formel et peu disponible, des outils inadaptés, une information peu structurée etc…

On peut cependant aller plus loin dans l’analyse en se concentrant sur les deux axes suivants : tout d’abord le projet, ensuite ceux qui le mènent.

Les projets ont pour la plupart les 3 aspects suivants :

• La performance (du produit, de la transformation, du process etc…)
• La conformité à l’attendu ou aux objectifs (cahier des charges par exemple)
• La sécurité ou la maîtrise des risques, souvent réglementaire.

Pour la performance, l’agilité peut souvent permettre de donner de bons résultats avec un effort raisonnable dans des délais maîtrisés. On va efficacement à l’essentiel et, on peut souvent être content du résultat obtenu, même si ce n’est pas encore 100% du requis.

Pour la conformité, il faut être exhaustif : qui se contentera d’une voiture rapide, livrée en un temps record, à laquelle il ne manque qu’une roue ? C’est là que le bât blesse : l’équipe a été agile, rapide, les informations, très orales, ont volé d’un acteur à l’autre. Il manque des petits détails par endroit, au bout de quelques itérations de ce jeu-là, ce n’est plus supportable.

Là où, par nature, l’agilité atteint plus encore ses limites, c’est pour la démonstration de sécurité, l’innocuité, gestion des risques, etc… l’activité est souvent très formelle, standardisée, méthodique pour des interlocuteurs qui attendent des éléments exhaustifs et précis. L’approche ne peut pas être la même. Un auditeur ne se laissera pas payer de mots, il voudra des preuves tangibles, des écrits, tout ce que n’est pas l’agilité.

En ce qui concerne les acteurs, l’activité peut être menée avec succès si les éléments suivants sont cohérents :

• L’expertise professionnelle des acteurs
• L’organisation des équipes
• La culture de l’entreprise, qui n’est autre qu’un ensemble de bonnes pratiques, une histoire collective et un moyen de se comprendre afin de créer une entité cohérente : l’entreprise.

Dans la pratique, le premier point ne pose pas de problème. Les deux autres points sont plus délicats : l’organisation est-elle légère (petits projets, petites équipes) ou lourde (gros programmes, grosses structures) ? Une organisation lourde est incompatible avec l’agilité. Quant à la culture, c’est presque une religion du fonctionnement en entreprise : doit-on écrire pour transmettre à l’entreprise ? Auquel cas c’est la fin de l’agilité. Peut-on se contenter de bien s’expliquer ? Les « post-it » iront alors décorer les tableaux, mais attention aux projets marathon sur plusieurs années avec des clients administratifs.

Les projets ayant pour la plupart les aspects performance, conformité et sécurité, une organisation donnée et une culture héritée de plusieurs années d’activité ne pourront être adaptées à toutes ces phases. Un gros projet verra souvent se heurter des défauts de type fonctionnarisation des collaborateurs, et des défauts de type papillonnage. Deux slogans résument les excès rencontrés :

– « parlez dans l’hygiaphone ! »

– « avec l’agilité, chacun fait ce qu’il veut, quand il veut, comme il veut, s’il veut… »

III

Comment s’en sortir ? Il ne faut pas mettre en œuvre l’agilité comme prétexte pour ne pas respecter des process établis. L’expérience a conduit l’auteur de ces lignes à constater qu’aucun projet global ne peut fonctionner en agilité pour tous ses volets. On a vu ci-dessus que certaines phases peuvent avantageusement être pilotées en mode agile. Attention, l’agilité ne signifie pas qu’on est incapable de faire un planning ou d’avoir une démarche méthodique, décrite et tracée, elle signifie que l’on peut prendre du recul avec des méthodes lourdes, éprouvées et convaincantes ; il y a donc un certain risque. Vouloir insuffler un peu d’agilité dans des processus existants est voué à l’échec : soit on mène de manière cohérente tout un projet ou un sous-projet en mode agile dans la totalité de son périmètre, soit on doit rester dans l’application des processus existants.

Le gros enjeu est d’assurer l’équilibre entre les deux fonctionnements, et dans la pratique bien identifier le temps et la manière selon lesquels il va falloir mettre et retirer l’agilité. Dans les faits, on arrive toujours à mettre de l’agilité dans des environnements sclérosés, et disons-le, parfois avec succès. Le côté moderne (et économique) de la démarche garantit à son promoteur une attention bienveillante des directions. Former et motiver une équipe dynamique, souvent jeune avec parfois un déficit méthodologique, à un fonctionnement plus lourd mais sécurisant et juste nécessaire pour le projet nécessite un vrai savoir-faire.

Cet enjeu devient de plus en plus crucial pour les entreprises structurées ou en voie de le devenir. C’est là aussi qu’un manager de transition chevronné et reconnu par les intéressés peut apporter une incontestable valeur ajoutée : assurer cet équilibre entre la maîtrise des processus et l’agilité dans le temps. Un bon usage du mode agile est de constituer un projet en mode agile pour créer ou modifier les processus existants, ou réaliser une transformation, mais par la suite, l’application des processus restera rigoureuse avec un nouveau processus.