Guide
Gestion de projet informatique : ce qui change vraiment
Les projets informatiques échouent moins sur la technique que sur trois traits du terrain : produit invisible, équipes partagées, existant qui doit continuer de tourner.
La gestion de projet informatique suit les mêmes fondamentaux que n’importe quel autre projet — périmètre, délai, coût, risque. Ce qui change n’est pas la méthode mais le terrain, et trois caractéristiques de ce terrain expliquent l’essentiel de la difficulté : ce qu’on construit ne se voit pas, ceux qui le construisent sont partagés avec d’autres projets, et le système existant doit continuer de fonctionner pendant toute la durée.
L’avancement n’est pas observable
Sur un chantier, tout le monde voit monter les étages. Sur un projet informatique, le seul signal visible est ce que quelqu’un déclare. C’est pourquoi l’avancement annoncé sur un logiciel dérive vers un chiffre confortable et y reste — les fameux 10 % derniers qui durent trois mois. La parade est de rendre l’avancement observable : du logiciel qui tourne à rythme fixe, une intégration continue plutôt qu’en fin de parcours, et des critères de recette écrits avant le développement plutôt que négociés après.
L’équipe n’est jamais dédiée
Les informaticiens sont partagés : le même architecte sert quatre projets, le même DBA se trouve sur le chemin critique de tout le monde, et le support de production passe avant tout dès qu’un incident s’ouvre. Un planning bâti sur la disponibilité nominale est donc faux dès le départ. Il faut planifier sur la capacité nette du support, des congés et des autres projets — ce qui est une question de portefeuille, pas de projet, et la principale raison pour laquelle les plannings informatiques glissent sans qu’aucun projet pris isolément n’ait rien fait de mal.
L’existant fait partie du périmètre
Très peu de projets informatiques partent d’une page blanche. Les interfaces avec les systèmes en place, la reprise des données, la cohabitation de deux versions pendant la transition et la réversibilité si le démarrage se passe mal sont rarement estimées sérieusement au cadrage, et elles pèsent couramment plus que la fonctionnalité nouvelle. Un cahier des charges qui ne décrit que la cible et ne dit rien de la transition a omis la moitié du projet.
Agile et planification ne s’opposent pas
La plupart des directions informatiques fonctionnent en hybride, qu’elles l’assument ou non : agile à l’intérieur des équipes, dates et budgets engagés à l’extérieur. Prétendre le contraire produit deux vérités déconnectées — un backlog qui dit une chose et un comité de pilotage qui en entend une autre. L’approche praticable consiste à planifier l’enveloppe et les jalons, à itérer à l’intérieur, et à réarbitrer le périmètre plutôt qu’à déplacer la date en silence.
Piloter des projets informatiques avec FoxPlan
FoxPlan tient les deux niveaux à la fois : un Gantt planifié avec jalons et budget pour les engagements, des tableaux agiles et des sprints pour le travail lui-même, et une capacité de ressources consolidée sur tous les projets — de sorte qu’un architecte partagé apparaisse comme une seule personne et non comme quatre. Le temps saisi par les équipes alimente à la fois l’avancement et le coût, ce qui permet de rendre compte d’un portefeuille informatique sans tableur parallèle.
