Philo SI

Je remercie Jean de m'avoir par son article décidé à enfin écrire ce billet.

Si je me souviens bien c'était en 2003, sur un projet important de refonte et d'uniformisation des systèmes Gestion comptable et Gestion commerciale dans un grand groupe pétrolier.
Un groupe d'utilisateurs référents avait été constitué pour la circonstance. Ils venaient des 6 coins de l'hexagone pour représenter les besoins de leur filiale. Ils avaient été rassemblés à Paris "La Défense" pour des ateliers de rédaction de spécification qui devaient durer un an.


Les chefs de projets informatiques pestaient devant la difficulté à faire comprendre aux référents utilisateurs qu'ils devaient travailler en "mode projet" (en fait tout décomposer en niveaux d'abstractions et en fonctionnalités selon les attentes des informaticiens). Ces super utilisateurs étaient pour la plupart issus de directions opérationnelles et leur environnement était plutôt le "mode production" .

Avant ça, je n'avais jamais réalisé pour ma part que je travaillais en "mode projet".

S'il est difficile à quelqu'un de basculer son comportement vers le "mode projet", c'est sans doute que ce dernier ne doit pas être trés naturel. Si faire des projets est un penchant humain, la façon d'aborder ceux-ci est loin d'être conforme à la méthode conçue dans le monde de l' informatique traditionnelle. J'ai d'ailleurs tendance à penser qu'il y a autant de méthodes que d'individus.

Le "mode projet" dont il est question dans le système d'information (mais pas que) est un comportement imposé, codifié, qui démarre par une étude théorique et qui termine par un tampon d'acceptation. Le chemin est balisé, il y a des passages obligés... bref ce mode de comportement doit obligatoirement être appris (et il n'est jamais totalement maîtrisé).

On peut parler longtemps du "mode projet" , en préciser le plan, la durée, les intervenants, le plan qualité, les risques… sans jamais définir quel est l'objet du projet. Le projet est un objet manipulable en soi.

On peut d'ailleurs définir quelques caractéristiques de cet objet : Il a une limite dans le temps, il est borné par un début et une fin, c'est une sorte de trou noir, l'information n'en sort pas naturellement…
Cet objet se manipule à l'aide de méthodes (il y en a plein) qui donnent les outils pour gérer le temps du projet, extraire l'information sélectionnée pour la diffusion…etc.

Ces méthodes ont toutes le même ADN de base , on y trouve inscrit les facteur temps (début-fin), information (validée), tâche(spécialisée), responsable(coupable), qualité (projet)... etc

Lorsqu'on aborde l'Agilité, on parle encore de projet. Méthode, pratique, nouveau type d'organisation….de projet.

J'accepte et j'utilise ce vocable principalement pour des raisons pratiques.

Pourtant, la mutation informatique vers l'Agilité (si elle réussit) remisera le "mode projet" au musée comme elle a remisé le langage procédural ou la base de données hierarchique (mais l'impact en sera sans doute bien plus grand).

Le mode de production Agile possède un génôme très différent de l'ADN des méthodes de projet. On y trouve des traces de temps (cycle), information(émulsion), taches(auto-affectées), responsable (collectif), qualité (produit) … etc.

Cet animal n'est pas équipé pour répondre au mode projet. Il est équipé pour attaquer la production logicielle comme celle d'un produit manufacturé. Un processus continu, une chaine de production qui adresse simplement des produits différents des assemblages matériels, des produits spécifiques au monde des théories (le monde 3 de Popper).

Cet ADN Agile est constitué de molécules "lean" adaptées au cycle de production matériel, ainsi que de molécules nouvelles, adaptées à l'injection de créativité tout au long du processus de production. Cet ADN évoluera avec la sélection naturelle mais jamais dans le sens du "mode projet".

Pour autant le projet n'est pas mort, il n'a pas vocation à disparaître. Il devrait même se renforcer, mais au niveau qui est le sien, celui de l'entreprise, celui des métiers.
Le projet c'est celui de l'entreprise, aborder un nouveau marché, simplifier la gestion comptable, réduire les coûts des opérations d'audit….

Le besoin de logiciel dans ces projets reviendra à lancer un nouveau besoin dans la chaine de production. Le lancement est standard, simple, rapide. La chaîne livre tôt et régulièrement du produit fini.
Bien sur, la façon de faire des projets va évoluer puisqu'elle était fortement empreinte des règles imposées par le "mode projet" du système d'information.

Cela va permettre d'adresser les besoins des projets métiers de façon plus rapide, plus intensive, de mettre en concurrence des solutions et de sélectionner ensuite les plus pertinentes, de répartir les budgets sur davantage de projets et de les pousser plus ou moins loin plus ou moins vite … et d'avoir la puissance des utilisateurs (ceux qui connaissent le micro management des informations) dans la boucle.

Mais ceci n'est pas encore écrit. Ou bien ça l'est ? Seulement si la fin des dinosaures était inéluctables...