La complainte d’un Chef de Projet : « ma feature n’est pas prête pour la semaine prochaine »

Planning, deadlines, priorités, budget, arbitrages, décisions, cadrage fonctionnel… Bienvenue dans le champ lexical du chef de projet IT. Un métier essentiel, mais souvent incompris. Le CP, c’est celui qui doit s’assurer que tout le monde est content, alors même que, bien souvent, personne ne l’est vraiment.

C’est ce que Sébastien nous raconte dans ce deuxième épisode de « La Complainte. » Chef de projet dans un grand groupe d’assurance depuis dix ans, il dévoile son quotidien : comment il est perçu par les métiers, par les équipes techniques, par la direction… et surtout, ce qu’il aimerait que l’on comprenne enfin sur son quotidien.

Un épisode riche de sens, parfois grinçant, mais sincère.
Place à la complainte.

Découvrir nos services d’ESN

Le récit qui suit est à la première personne, tel qu’il nous a été confié. Toute ressemblance à votre quotidien… est une ressemblance à votre quotidien.

Je m’appelle Sébastien [ndlr : prénom modifié pour préserver la complainte], et depuis plus de dix ans, je suis chef de projet informatique dans un grand groupe de l’assurance. J’ai commencé dans la technique, en développement puis en analyse applicative. Mais assez vite, j’ai eu envie de prendre du recul, de comprendre la logique des processus et de jouer un rôle plus transversal. C’est comme ça que je me suis dirigé vers la gestion de projet : j’aimais organiser, clarifier, structurer.

On pense souvent savoir ce qu’est mon métier. “Tu planifies ? Tu organises ? Tu suis le projet ?” En effet, c’est la partie visible. Sur le papier, mon travail consiste effectivement à cadrer les besoins, définir les jalons, planifier, rédiger les specs, organiser la recette et accompagner les équipes.

Mais la réalité n’est pas aussi limpide.
Dans les faits, mon rôle, c’est surtout de créer un cadre clair pour que l’équipe technique puisse se concentrer sur son développement, et pour que les directions métiers disposent en temps voulu des livrables dont elles ont besoin pour avancer.

Je travaille au quotidien avec les Techs Managers et les métiers pour fixer des échéances réalistes, préparer les livraisons et identifier les risques. J’essaie de maintenir tout le monde dans le même mouvement.

En ce moment, je pilote un projet d’automatisation dans un service métier stratégique. Mon objectif est de présenter une version solide à la direction, suffisamment fiable pour démontrer la valeur, dans les temps qu’on m’a imposés. Je ne construis pas la solution moi-même, mais si elle n’est pas prête le jour J, c’est vers moi qu’on se tourne.

Voilà pourquoi le rôle de chef de projet est souvent mal compris.
Derrière le mot “projet”, il y a tellement de variables qu’on a vite fait de résumer ça à “il planifie”.
Je peux le comprendre. Mais j’aimerais aussi qu’on perçoive ce que ça demande vraiment de porter ce fameux projet… et de lui donner du sens.

Quand on me confie un projet, on me confie surtout une triple contrainte : le périmètre, les délais et le budget. Au début, tout paraît propre, logique, atteignable. On “vise la lune”, un peu naïvement parfois.

Et puis, on creuse, on parle avec le Tech Manager, avec les équipes techniques, avec les métiers… et on réalise que ce n’est jamais aussi simple que prévu.

Le besoin bouge très souvent. Et on entend “c’est pas faisable dans ce délai” ou “on a pas les ressources pour ça”. Et moi, je me dis que ma feature n’est pas prête pour la semaine prochaine, comme on l’avait prévu dans le planning.

Le risque c’est de dire oui à tout, ou trop vite. Avec le temps, j’ai appris que ma plus grande compétence, c’est justement de savoir dire non ou plutôt dire “je regarde et je reviens vers toi”. Sinon, tout le monde est frustré. Les équipes techniques sont sous pression et les directions métiers n’ont pas ce qu’elles veulent dans les temps. 

Aujourd’hui, ma règle, c’est : je prends la demande, j’étudie, et je reviens avec un vrai diagnostic. C’est ma façon d’être honnête avec tout le monde.

Il m’arrive, délibérément, d’esquiver des demandes. Tout ne peut pas être traité au même niveau d’urgence. Parfois, quand une demande arrive un peu floue, pas prioritaire, ou clairement pas mûre pour bousculer les encours, je me contente de dire : “Oui, je regarde et on en reparle”. Et… je laisse un peu filer.

Si je n’en entends plus parler, c’est qu’elle n’était ni urgente ni essentielle. Ça évite de surcharger les équipes pour quelque chose qui n’est pas prioritaire. Et c’est aussi ça, mon rôle : protéger le projet en filtrant avant que ça ne dérive.

Par contre, si la demande revient, là je la prends. Je vois d’abord avec le Tech Manager pour estimer à la louche ce que ça représente en charge, en ressources et en risques. Puis, je mets la demande en regard de la roadmap : les jours de développement nécessaires, les personnes à mobiliser, les impacts attendus, le budget. Et j’explique très simplement : “Si on veut l’intégrer maintenant, on doit soit reporter une autre fonctionnalité, soit en remplacer une. Tu préfères qu’on décale quoi ?”

En général, ça suffit à rendre visible ce que les gens ne voient pas : chaque demande a un coût, une place, et une conséquence.

Le plus dur pour moi, c’est le stress. C’est la conséquence directe de cette sur-anticipation permanente que j’ai développée. Je suis le premier que les métiers appellent quand quelque chose coince, même si ce n’est pas moi qui ai les mains dans la technique. Je suis celui à qui on demande d’expliquer un retard, de justifier un dépassement ou de rassurer la direction.

La pression arrive de partout : du haut, des côtés, parfois même du terrain. Il faut encaisser sans transmettre, ou du moins filtrer. Ça demande une énergie folle.

Ça fait dix ans que je fais ce métier, donc j’ai développé mes propres rituels pour gérer ça. Mais ça reste là, en toile de fond.

Puis, je dirais la solitude de certaines décisions. C’est paradoxal, parce que mon travail consiste justement à consulter plein de gens pour définir un cadre commun. Mais au moment de trancher, je n’ai pas le droit au doute. Mes décisions ont un impact sur plusieurs équipes. Souvent, je dois me prononcer alors que je n’ai pas toutes les informations, ou que les avis ne convergent pas du tout.

Et puis il y a ce rôle un peu particulier de traducteur incompris. Je dois défendre des choix techniques auprès des métiers, leur expliquer qu’un “petit ajustement rapide” peut avoir bien plus de conséquences qu’ils ne l’imaginent. Et à l’inverse, je dois justifier les besoins métiers aux équipes techniques, qui les voient parfois comme un caprice alors que c’est profondément lié à leurs usages, à leurs contraintes réglementaires ou à leurs clients. Chacun voit son morceau du tunnel. Moi, je dois voir la longueur totale.

Donc, oui ça m’arrive de douter, même souvent.
Quand je valide un planning alors que je sais que l’équipe est déjà à flux tendu.
Quand on me demande un engagement ferme alors que rien n’est stable.
Ou quand je sens que je ne suis plus tout à fait du côté technique, ni complètement du côté métier.

Venez passer une journée avec moi, je vous montre ce que je fais vraiment.
Je ne suis pas là pour dire oui à tout, ni pour mettre la pression aux équipes.
J’essaie juste de tenir la route au milieu de beaucoup de choses que je ne contrôle pas toujours.

Voilà, je crois que c’est pas mal.
Merci d’avoir écouté ma complainte.