6 ans en gestion de projet tech : mes 5 plus grandes leçons

En 2018, je démarrais ma carrière comme développeuse. J'écrivais du code, je résolvais des problèmes techniques, et je pensais que la qualité d'un projet se mesurait à la propreté du code et à l'élégance des solutions.

Aujourd'hui, en 2025, après avoir traversé plusieurs rôles — développeuse, chef de projet, Scrum Master data, présidente d'association, et maintenant Product Manager — j'ai une vision complètement différente de ce qui fait réellement réussir un projet.

Spoiler : ce n'est pas le code. Ce n'est même pas toujours la méthodologie.

Voici les 5 leçons que j'aurais aimé connaître plus tôt. Des leçons apprises sur le terrain, parfois dans la douleur, mais qui ont radicalement transformé ma manière de travailler.

Leçon 1 : La communication écrite vaut mieux que la communication orale

Ce que j'ai appris (à mes dépens)

En 2022, je pilotais le projet Platform Data : un POC de dashboard d'indicateurs clés pour le pilotage d'activité. Application React, data visualization, KPI en temps réel. Sur le papier, tout roulait.

J'étais convaincue que je communiquais bien. Je faisais des points réguliers avec l'équipe, je remontais les infos au COO de manière informelle, je répondais aux questions. Dans ma tête, tout le monde était aligné.

Erreur.

Un jour, le COO me demande où en est le projet. Je lui fais un point oral. Il fronce les sourcils : "Attends, on n'avait pas validé cette orientation. Et pourquoi ce délai ?"

J'ai réalisé mon erreur : je communiquais, mais je ne laissais pas de trace. Pas de compte-rendu de réunion. Pas d'email de synthèse hebdomadaire. Pas de dashboard de suivi accessible. Le COO n'avait aucune visibilité.

Ce que j'en ai tiré

Depuis, j'applique une règle simple : ce qui n'est pas écrit n'existe pas.

Concrètement :

• ✅ Chaque réunion importante → compte-rendu envoyé dans les 24h

• ✅ Chaque semaine → email de synthèse aux stakeholders (3 sections : Fait / En cours / Blocages)

• ✅ Chaque décision majeure → trace écrite avec contexte et justification

Pourquoi ça change tout :

• Cela crée de la visibilité pour ceux qui ne sont pas dans le quotidien du projet

• Cela évite les malentendus et les "mais je pensais que..."

• Cela permet de documenter les décisions et de s'y référer plus tard

Mon conseil : Arrêtez de croire que parler suffit. Écrivez. Toujours. Même un simple email de 5 lignes vaut mieux qu'une conversation de 30 minutes sans trace.

Leçon 2 : Mobiliser une équipe, c'est d'abord créer du sens

L'histoire qui m'a marquée

En 2021, j'ai créé et présidé S'Citoyen, une association étudiante pour soutenir une école primaire rurale dont la salle informatique avait été endommagée par un dégât des eaux. Notre mission : collecter des fonds et du matériel pour les aider.

Le défi ? Mobiliser des étudiants bénévoles avec :

• Des emplois du temps complètement différents

• Pas d'enfants (donc pas d'identification naturelle avec une école primaire)

• Des lieux d'habitation éloignés de l'école bénéficiaire

• Aucune rémunération

Autrement dit : comment convaincre des gens de donner de leur temps gratuitement pour un projet qui ne les concerne pas directement ?

Ma stratégie : Créer du sens et de la fierté.

Je ne leur ai pas vendu "on va collecter des dons". Je leur ai vendu "vous allez changer la vie de dizaines d'enfants qui n'ont pas accès à l'informatique en 2021". Je leur ai montré des photos de l'école, des témoignages. On s'est rendu dans l'école pour qu'ils se rendent compte de l'impact qu'ils pourraient avoir et ce qui changera grâce à eux. Je leur ai fait visualiser l'impact.

Résultat : Nous avons collecté plusieurs milliers d'euros en dons financiers et matériels. Des étudiants qui n'avaient jamais fait de bénévolat ont donné des heures de leur temps. Certains sont travaillés le week-end pour donner chaque euros gagné.

Ce que j'applique aujourd'hui en tant que PM

Une équipe qui ne comprend pas pourquoi elle travaille sur un projet n'est jamais aussi performante qu'une équipe qui en comprend l'impact.

Avant chaque projet, je pose ces questions à l'équipe :

• 👤 Pour qui travaillons-nous ? (utilisateur final, pas le "client")

• 🎯 Quel problème résolvons-nous vraiment ?

• 📊 Comment saurons-nous que nous avons réussi ? (impact mesurable)

Mon conseil : Arrêtez de motiver avec des deadlines et des roadmaps. Motivez avec du sens et de l'impact. Les gens veulent savoir que leur travail compte.

Leçon 3 : Gérer les conflits est la compétence la plus difficile (et la plus importante)

La compétence que j'ai évitée le plus longtemps

Pendant longtemps, j'ai fui les conflits. Quand deux membres de l'équipe n'étaient pas d'accord, j'essayais de trouver un compromis mou. Quand un stakeholder demandait l'impossible, j'acquiesçais pour éviter la tension. Quand une décision technique divisait l'équipe, je reportais la discussion.

Résultat : Les conflits ne disparaissaient pas. Ils s'envenimaient. Les tensions s'accumulaient. Et au final, c'était pire.

Ce que j'ai appris en gérant une entreprise

Entre 2018 et 2020, j'étais bras droit du dirigeant de Janney E.T, une entreprise d'installation de fibre optique. Je gérais toute la partie administrative, mais aussi la coordination des équipes terrain. Des techniciens, du matériel, des chantiers, des deadlines serrées.

Un jour, deux techniciens s'opposent frontalement sur la méthode d'installation sur un chantier. Chacun est convaincu que sa technique est la bonne. Le ton monte. L'ambiance devient électrique sur le chantier. Je ne peux plus fuir.

À ce moment-là, j'aurais pu :

• Trancher autoritairement (risque : frustrer celui dont la solution n'est pas retenue)

• Laisser faire en espérant que ça se règle (risque : conflit qui s'envenime et retarde le chantier)

• Faire appel au dirigeant (risque : perdre ma crédibilité)

J'ai appris que gérer un conflit, ce n'est pas l'éviter. C'est :

1. L'accueillir : "Ok, il y a un désaccord. C'est normal et c'est sain."

2. Écouter vraiment chaque partie (sans juger ni trancher trop vite)

3. Clarifier les positions : souvent, on se dispute parce qu'on ne parle pas de la même chose

4. Faciliter la résolution : pas imposer MA solution, mais aider l'équipe à trouver LA solution

Ce jour-là, j'ai pris 30 minutes sur le chantier. Chacun a exposé sa méthode. J'ai posé des questions : "Pourquoi cette technique ? Quels sont les risques de l'autre méthode ?" On a listé les pour/contre. Au final, ils ont trouvé eux-mêmes une solution hybride qui prenait le meilleur des deux approches.

Le chantier a repris. Et surtout, ils sont repartis en ayant appris l'un de l'autre.

Mon conseil : Le conflit n'est pas l'ennemi. L'absence de confrontation saine, si. Apprenez à faciliter les désaccords au lieu de les étouffer.

Leçon 4 : Écrire clarifie la pensée (et sauve des projets)

La conviction que j'ai développée avec le temps

Si vous m'aviez demandé il y a 6 ans quel était mon super-pouvoir en gestion de projet, j'aurais probablement dit "je suis organisée" ou "je sais coder".

Aujourd'hui, ma réponse est différente : je sais écrire pour clarifier.

Pourquoi l'écriture est devenue mon outil principal

Gérer un projet, c'est gérer le chaos :

• Des demandes contradictoires de stakeholders

• Des contraintes techniques floues

• Des équipes qui ne parlent pas le même langage

• Des priorités qui changent chaque semaine

L'écriture est l'antidote au chaos.

Quand je note :

• Les remarques d'un stakeholder → je structure sa pensée (et souvent, il se rend compte que ce n'était pas si urgent)

• Les user stories → je force l'équipe à préciser le "pourquoi" avant le "comment"

• Les décisions prises en réunion → je fige le contexte pour éviter de revenir en arrière

• Les risques identifiés → je les rends visibles et actionnables

Exemple concret : Sur le projet Datahub, je maintenais un document Confluence "Décisions & Contexte" où chaque choix majeur était documenté avec :

• 📌 La décision prise

• 🤔 Le problème qu'elle résolvait

• ⚖️ Les alternatives considérées

• 📊 Les critères de choix

Résultat ? Six mois plus tard, quand un nouveau membre de l'équipe demandait "mais pourquoi on fait comme ça ?", la réponse était là. Pas besoin de re-débattre.

Mon conseil : Prenez des notes. Tout le temps. Même (surtout) quand ça semble évident. Ce qui est clair dans votre tête aujourd'hui sera flou dans 3 mois.

Leçon 5 : Écouter toutes les parties prenantes (vraiment écouter) est un super-pouvoir

Ce que j'aurais dû comprendre plus tôt

Au début de ma carrière, j'écoutais les stakeholders pour répondre. Je voulais avoir la solution, vite. Montrer que j'étais compétente, que je maîtrisais.

Erreur.

Ce que "écouter" veut vraiment dire

Écouter, ce n'est pas attendre son tour de parler. C'est :

• 🎧 Se taire et laisser l'autre finir (vraiment finir, même si c'est long)

• 🤔 Reformuler pour vérifier qu'on a bien compris : "Si je résume, ton besoin c'est..."

• ❓ Poser des questions au lieu de proposer des solutions trop vite

• 📝 Noter pour montrer que ça compte (et ne pas oublier)

Exemple concret : Sur le projet Dynascreen (application d'affichage dynamique), le client nous demandait une nouvelle feature qui semblait complexe et peu prioritaire. Mon premier réflexe : "Ça va prendre du temps, ce n'est pas dans le scope."

Mais j'ai pris 30 minutes pour vraiment écouter. Pourquoi il voulait ça. Quel problème ça résolvait pour lui. Comment il imaginait l'utiliser.

Résultat : Il ne voulait pas cette feature. Il voulait résoudre un problème de communication interne. J'ai proposé une solution beaucoup plus simple (déjà dans l'app) qu'il ne connaissait pas. Problème résolu en 10 minutes.

Ce que ça change

Quand vous écoutez vraiment :

• ✅ Vous résolvez le vrai problème (pas celui exprimé en surface)

• ✅ Vous évitez de développer des features inutiles

• ✅ Vous créez de la confiance (les gens sentent qu'ils comptent)

• ✅ Vous anticipez les difficultés avant qu'elles ne deviennent des crises

Mon conseil : La prochaine fois qu'un stakeholder vous fait une demande, ne répondez pas tout de suite. Posez 3 questions. Écoutez vraiment. Prenez des notes. Vous verrez, la solution sera souvent différente de ce que vous pensiez.

Conclusion : De développeuse à Product Manager, ce qui a vraiment changé

Il y a 6 ans, je pensais que gérer un projet, c'était :

• ❌ Planifier à la perfection

• ❌ Maîtriser la technique

• ❌ Respecter les délais

Aujourd'hui, je sais que gérer un projet, c'est :

• ✅ Communiquer (et laisser des traces)

• ✅ Créer du sens (pour mobiliser)

• ✅ Gérer les conflits (au lieu de les fuir)

• ✅ Écrire pour clarifier (le chaos)

• ✅ Écouter vraiment (toutes les parties prenantes)

Ces 5 leçons ne sont pas théoriques. Je les applique chaque jour. Elles ont transformé ma manière de travailler, de gérer des équipes, et de livrer des projets qui ont de l'impact.

Et ce n'est que le début. Parce que chaque projet m'apprend quelque chose de nouveau. C'est ça qui me passionne dans ce métier.

Et vous ?

Quelle est la leçon la plus importante que vous avez apprise en gestion de projet ?

Si cet article résonne avec vous, n'hésitez pas à me le dire. Et si vous cherchez un profil Product Manager avec une vision terrain, parlons-en.