« Les fondations du changement ! »
Les lois que tout chef de projet a vécues
des projets informatiques échouent.
Pas par manque de talent — par manque de pilotage.
La loi des objectifs flottants.
On lance le projet. Chaque partie prenante a compris quelque chose de différent : ce qu'on livre, pour qui, dans quel délai. La mauvaise compréhension des attentes et de l'envergure du système est la première cause d'échec recensée. Le triangle d'or — qualité, coûts, délais — est brisé avant même d'avoir commencé.
La loi des objets intangibles.
Un logiciel ne se voit pas pousser. On ne mesure pas l'avancement d'un développement comme on voit monter des murs. Cette invisibilité rend l'estimation structurellement difficile : un projet mal planifié prend trois fois plus de temps que prévu, un projet bien planifié en prend deux fois plus. Et si on tolère les changements en cours de route — et on les tolère toujours — le rythme de changement finit par dépasser le rythme de progrès.
La loi de la planification de façade.
Le plan existe. Il est réaliste le jour J. Mais personne n'assure le contrôle en cours de route. Faiblesse dans la planification et le contrôle : deuxième famille de causes d'échec. Le plan ne pilote pas le projet — il décore le rapport de lancement.
La loi du silence.
La direction ne soutient pas. L'équipe ne remonte pas. Le client n'est pas dans la boucle. Communication inadéquate, structure décisionnelle défaillante, manque de culture partagée : autant de facteurs qui transforment un projet en boîte noire où les mauvaises nouvelles arrivent trop tard.
L'effet tunnel.
Les projets progressent rapidement jusqu'à ce qu'ils soient terminés à 90 %. Par la suite, ils demeurent à 90 %. Tout va bien, aucune alerte, l'équipe est confiante… parce que personne ne voit rien. La visibilité revient à la livraison — trop tard.
La loi de Murphy.
Lorsque les choses vont bien, quelque chose ne va pas. Lorsque les choses ne peuvent être pires, elles le deviendront encore plus. Lorsque les choses semblent aller mieux, c'est qu'on a oublié quelque chose. Dans un projet, si plusieurs issues sont envisageables, c'est vers la moins favorable que le processus s'orientera.
Comment y échapper ?
Les fondations ne changent pas. Ce qui change, c'est la façon de les poser — et de les tenir.
Assurer les fondamentaux de la gestion de projet
Comprendre les spécificités des projets informatiques. Développement ou maintenance d'un système d'information — avec ses composantes infrastructure, applicative et humaine. Le périmètre d'abord, le reste ensuite.
Distinguer activités d'ingénierie et de gestion. Un projet de développement combine des activités d'ingénierie logicielle (conception, réalisation, test) et des activités de gestion (pilotage, qualité, configuration). Les deux doivent être planifiées, pas seulement les premières.
Formaliser un plan de conduite. Le plan de conduite définit le scénario du projet : découpage en phases et tâches, cycle de vie choisi, méthode de conception. Sans lui, chaque projet réinvente son propre chaos.
Choisir sa méthode. Merise, RUP, RAD, XP, Scrum… Le choix n'est pas anodin. Il conditionne le cycle de vie — cascade, semi-itératif, itératif — le rythme des livrables et la façon dont les équipes collaborent.
Ancrer dans un référentiel normatif. CMMi, ISO 9001, SPICE… Les activités de gestion dépendent du référentiel qualité adopté. Sans ce cadre, le plan de gestion reste une liste de bonnes intentions.
Clarifier les rôles. Direction, chef de projet, équipe, client : chacun a une mission précise. Le chef de projet n'est pas un technicien qui gère — c'est un pilote qui communique, arbitre et rend compte.
Les supports ci-dessous datent de mes années d'enseignement à l'IUT de Belfort (2007-2020). Les principes qu'ils énoncent restent ceux d'une conduite de projet rigoureuse — précisément ce qui manque à l'heure du développement augmenté, et que mes travaux actuels actualisent.
M01 · 2007 — La Gestion de projet
Le socle. Qu'est-ce qu'un projet informatique, pourquoi 70 % échouent, comment structurer un plan de développement et qui fait quoi. Tout y est, y compris le triangle d'or.
Télécharger le PDF downloadM02 · 2007 — Méthodes de conduite de projet
Le choix stratégique. Du cycle en cascade à l'agilité (XP, RUP, RAD) : les grandes méthodes, leurs cycles de vie, leurs forces et leurs compromis. Ce support répond à la question que tout chef de projet évite : quelle méthode pour quel projet ?
Télécharger le PDF downloadM03 · 2007 — Normalisation des processus
Le cadre de rigueur. ISO 9001, CMMi, SPICE : les référentiels qui donnent à votre plan de gestion son ossature et sa crédibilité. Avec la réponse à la vraie question : pourquoi normaliser ne suffit pas — il faut aussi maîtriser.
Télécharger le PDF downloadÀ l'heure de l'IA, faut-il inventer une nouvelle approche ?
L'IA accélère les tâches d'ingénierie et de gestion — mais elle introduit un biais dangereux : elle pousse à brûler les étapes. Toute phase d'analyse — des besoins, des risques, du contexte, des parties prenantes — exige du temps, des itérations, une maturation que l'IA ne sait pas respecter. Elle propose vite, elle produit vite, elle convainc vite. Et c'est précisément là le piège : on passe de l'analyse à la réalisation sans avoir vraiment pensé.
L'analyse perd en profondeur, s'égare sur des faux problèmes, passe à côté des signaux faibles. Les résultats se normalisent, l'innovation s'étiole. Et quand le contrôle lui-même est délégué, c'est qu'on ne maîtrise plus rien.
Ces changements dessinent un territoire où l'expérience du pilotage rencontre des paradigmes neufs — et où chaque organisation doit trouver sa propre voie.
Maîtriser les fondamentaux est toujours nécessaire bien sûr, mais ne suffit plus.
Il faut les penser à l'heure du développement augmenté.
C'est cette double démarche — s'approprier les principes et les actualiser face à l'IA — qui distingue aujourd'hui les organisations qui pilotent vraiment leurs projets de celles qui se laissent emporter.
C'est justement l'objet de mes travaux.
En savoir plus arrow_forward
