“Ça a l’air simple” : la phrase qui met le plus de projets IT en difficulté.

Le scénario est devenu un classique: En entreprise, le point d’entrée du besoin n’est pas l’IT. C’est le métier.

Un utilisateur exprime un besoin : il a vu une fonctionnalité ailleurs, il pense qu’elle est “facile à implémenter”. Le ROI est calculé, l'enthousiasme est là. Le projet est "vendu" comme une évidence simple à mettre en place.

Sauf qu'entre l'idée ("Le Quoi") et la réalisation ("Le Comment"), il y a souvent un monde que l'on ignore volontairement.

Et l'erreur fatale est que l'IT a été consulté trop tard.

Ce qui semble être une "simple évolution" en surface peut se révéler être un séisme structurel pour le SI. Non pas parce que l'idée est mauvaise. Mais parce que l'écosystème existant n'est pas conçu pour l'accueillir sans risque de déstabilisation majeure.

Lancer un tel projet sans audit préalable, c'est s'engager sciemment vers une dérive budgétaire et une dette technique immédiate.

C'est précisément ici que le rôle du Chef de Projet IT prend tout son sens. Je ne suis pas là uniquement pour organiser et suivre le planning une fois le train lancé.

Mon intervention est cruciale en amont du Kick-off, lors de la phase de Cadrage Technique. Avec l'équipe IT, mon rôle est d'auditer la faisabilité réelle avant de s'engager :
- Analyse d'Impact : Cartographie des flux existants vs cibles.
- Urbanisation : Vérification de la cohérence avec l'architecture d'entreprise (éviter le code "spaghetti").
- Gouvernance : Qui est propriétaire de la donnée ? Quel système est maître ?

Un chef de projet IT n’est pas seulement celui qui fait avancer un projet. Il est souvent celui qui évite qu’un projet commence sur une illusion de simplicité.