Histoire d'Ecoplanningpar Claude Rivoiron
À la fin des années 1970, le premier logiciel Ecoplanning ne ressemblait pas à ce qu'on imagine aujourd'hui d'un outil de gestion de projet. Il ne servait pas, d'abord, à dessiner un planning. Il servait à le simuler.
C'est cette différence — apparemment subtile — qui a fait son utilité dès le départ. Et qui structure encore, près de cinquante ans plus tard, la philosophie du logiciel.
L'idée : le tableau de bord simulable
Le concept s'appelait à l'époque le tableau de bord simulable. L'idée venait directement du chantier de la Tour Totem au Front de Seine — un IGH de trente-deux étages que je coordonnais en 1975, et dont les contraintes d'exécution (trois types de coffrages, grue intérieure, façades en sept grappes de mur-rideau) rendaient illusoire l'idée d'un planning établi une fois pour toutes.
Ce qu'il fallait, sur ce chantier comme sur les suivants, ce n'était pas un planning « parfait » écrit à la signature du marché. C'était la capacité, à n'importe quel moment, de faire varier rapidement la durée de chaque phase et de voir l'effet sur l'ensemble.
Si la phase « gros œuvre » dérapait de trois semaines, pouvait-on contracter la phase « finitions » pour rentrer dans le délai contractuel ? De combien ? Avec quel impact sur les autres lots ? Et si on prenait le pari inverse — dilater la phase « études » pour mieux préparer l'exécution, qu'est-ce qu'on devait raccourcir ailleurs ?
Sur un planning papier, ces questions exigeaient de redessiner toutes les barres une à une, à la gomme. Sur Ecoplanning, dès 1979, elles devenaient des leviers.
L'Apple II, l'Epson, et un cadre de simulation
La première version tournait sur un Apple II avec une imprimante à aiguilles Epson en A4. La résolution graphique de l'époque ne permettait pas grand-chose en termes de visualisation — il fallait deviner les barres dans les hachures du listing. Mais le moteur de calcul, lui, faisait ce qu'on lui demandait : on définissait des tâches-clés qui partageaient le projet en plusieurs périodes, et on entrait un pourcentage de contraction ou de dilatation pour chacune.
Si la période A devait passer de cent à cent-cinquante pour cent (allongement de 50 %), le logiciel ajustait par homothétie la durée de toutes les tâches qu'elle contenait, ainsi que les décalages des liens. L'ordonnancement restait intact. Les marges étaient recalculées. Le chemin critique se réajustait.
En quelques minutes, on avait une nouvelle version du planning. On pouvait en faire trois ou quatre dans une réunion d'analyse et ne retenir que la plus crédible.
Pourquoi la simulation, pas la planification
Le choix initial de structurer le logiciel autour de la simulation n'était pas une coquetterie technique. Il venait d'une conviction forgée sur les chantiers des Halles de Rungis, de l'ensemble Le France, et de la Tour Totem :
Un planning rigide est un planning faux.
Pour des projets importants et complexes, on ne peut pas espérer écrire le planning prévisionnel correct du premier coup. Les hypothèses initiales sont nécessairement incomplètes. Les contraintes apparaissent en cours d'analyse. Les retards arrivent dès les premières phases. La seule façon de garder le planning utile dans la durée, c'est de pouvoir le remodeler vite.
La simulation rendait cela possible. Pas seulement à la création — mais aussi en cours de projet. Quand une dérive s'installait, on ne refaisait pas tout : on simulait le rattrapage sur les phases à venir, on regardait si le délai contractuel restait atteignable, on arbitrait.
La trace dans Ecoplanning d'aujourd'hui
Près de cinquante ans plus tard, le logiciel a beaucoup changé — interface graphique, base de données en osmose avec le planning, gestion multi-projets, lissage des ressources. Mais la démarche simulation est restée au cœur du fonctionnement. Elle est notamment ce qui permet :
- D'obtenir rapidement l'ébauche d'un planning prévisionnel à partir d'un calendrier décisionnel mémorisé d'un type de projets — sans repartir de zéro.
- D'insérer un projet dans des objectifs de délai imposés par le maître d'ouvrage en contractant les phases possibles et en identifiant celles qui ne peuvent pas l'être.
- De prendre une marge de sécurité sur les phases mal perçues d'un projet, en les dilatant légèrement plutôt qu'en ajoutant artificiellement des tâches tampon.
- De recaler le projet après une dérive sans tout reconstruire.
Au-delà de l'outil, c'est aussi une façon de penser le management de projet. Un planning n'est pas un contrat figé entre le passé et le futur. C'est une représentation de ce qu'on sait à un instant donné, qui doit pouvoir évoluer avec ce qu'on apprend.
L'antériorité déposée (n° 13 53261)
L'idée a fait l'objet d'un dépôt d'antériorité auprès de l'INPI (enveloppe Soleau, n° 13 53261), sous la formulation « Actualisation rapide vs Affiner Actualisation ». Deux démarches distinctes : la première pour connaître au plus tôt les conséquences d'un retard, la seconde pour décider de la manière d'y répondre. La simulation est la mécanique commune aux deux.
Ce dépôt ne « protège » rien — une enveloppe Soleau date une idée, elle n'accorde pas de monopole. La démarche elle-même est d'ailleurs suffisamment décrite dans les ouvrages pour qu'un autre éditeur de logiciel l'implémente s'il le souhaite. C'est plutôt une trace documentée d'une idée qui n'a jamais été reprise telle quelle ailleurs, et qui mérite d'être attribuée à son origine : un chantier parisien des années 1970, et un Apple II qu'on programmait la nuit parce que c'était l'ordinateur disponible.
Tags