Pourquoi les lancements de projet échouent pour les nouvelles recrues
Le mythe du lancement: Les lancements de projet créent une cohésion initiale, mais la situation évolue forcément.
L’importance de l’appropriation: Si les nouvelles recrues n’ont pas d’appropriation, l’élan, le moral et l’impact du projet en pâtissent.
Le défi de la documentation: La documentation traditionnelle échoue dans les projets rapides : il faut des formats légers et adaptables.
IA & Neurodiversité: Les outils IA peuvent faciliter l’intégration en rendant le projet accessible, à condition d’avoir des données fiables.
Une culture de l’appartenance: Créer un sentiment d’appartenance est essentiel pour une intégration efficace et la réussite du projet.
Pourquoi les lancements de projet sont excellents… mais imparfaits
J'adore un bon lancement de projet. C'est une occasion de créer de l'enthousiasme, d'impulser une dynamique et de favoriser l'alignement avec toutes les bonnes personnes réunies.
Sauf que... les lancements de projet sont un mythe total.
Du moins, cette version-là l'est.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
La version où l'on regroupe tous les parties prenantes connues, où l'on s'accorde sur un cap commun, grave notre approche dans le marbre, puis où l'on démarre en pensant que l'énergie créée ce jour-là suffira à mener le projet du début à la fin.
La réalité, c'est que le changement est inévitable et que la plupart des méthodes d'organisation des lancements de projet sont en réalité défaillantes.
Et cela va devenir un enjeu majeur dans l'économie de travailleurs fractionnés et alimentée par l'IA dans laquelle nous entrons.
Pourquoi un bon lancement ne garantit pas un bon projet
Je pensais auparavant que ma capacité à mener de bons lancements de projet était mon avantage injuste en tant que chef de projet. Lorsque je lançais mes projets, les équipes démarraient sur les chapeaux de roue, claires sur les enjeux, pleines d'élan, loin de la confusion et des questions sans réponse.
En fait, il arrivait que des personnes viennent me voir après un lancement pour me demander d’emprunter mon ordre du jour ou mon support afin de l'utiliser dans leurs propres projets. J'en étais fier.
Mais un événement a totalement changé ma perception des lancements de projet.
Sur l'un de mes projets, des membres clés de mon équipe ont été déplacés et affectés à d'autres projets — sans avoir le temps d'assurer un transfert de connaissances correct. Les personnes talentueuses qui les ont remplacés étaient aussi très compétentes, mais elles avaient l'impression de commencer en retard, vivant dans l’ombre de ce qui avait déjà été accompli. Elles nuançaient chacune de leurs interventions avec « mais je n’étais pas là au début du projet » ou « je ne fais que rattraper mon retard ici, ne laissez pas mes suggestions perturber vos plans ».
Pour les nouveaux membres de l'équipe, le problème n'était pas un manque d'information, d'autorité ou même d'idées, mais qu'ils ne se sentaient pas propriétaires du projet.
Et sans appropriation, le projet perdait de son élan. La mission n’était pas la leur. Ils avaient l’impression d’être des enseignants remplaçants coincés à gérer une situation subie, sans réel pouvoir de décision.
Malheureusement, je ne l'avais pas encore compris.
Le problème du transfert de connaissances
À l'époque, la solution me paraissait simple : il suffisait de mettre les nouveaux au courant. Il n’y avait qu'à transférer les connaissances dans leur esprit. Non ?
Après tout, il y avait des briefs, des cahiers des charges et des documents de besoins en pagaille — sans parler du support de lancement et des livrables issus des ateliers de vision.
Mais même avec tous vos documents projet propres et organisés, l'expérience du nouveau collaborateur qui doit assimiler une montagne d’informations hétérogènes peut ressembler à un audit comptable forensique, sous pression.
Certes, les nouveaux peuvent poser des questions, mais ils ne savent pas ce qu’ils ignorent. Et la plupart du temps, ils n’osent pas encore poser les « questions bêtes », de peur d’obtenir la fameuse réponse : « c’était dans la doc, tu ne l’as pas vu ? »
Cela créait un cercle vicieux où les nouveaux restaient perdus plus longtemps — ce qui ne faisait que compliquer la gestion du projet.
Le problème d’hygiène documentaire
Et en plus, à chaque fois que j’intégrais un nouveau membre dans mon équipe, je me rendais compte qu’au sein de mes précieux documents, de petits détails — parfois même des éléments majeurs — n’étaient plus en phase avec la réalité du projet.
Depuis le lancement, des centaines de milliers de micro-décisions avaient été prises. Pas celles que l'on consigne dans un registre, mais toutes celles, infimes, qui échappent aux mises à jour de la documentation.
Je me retrouvais donc à expliquer les écarts, à détailler les subtilités, à relayer des conversations informelles entre collègues dont nous n’avions jamais imaginé garder une trace.
Le problème de vitesse
Aurais-je pu atténuer tout cela en instaurant un « binôme » pour que le nouvel arrivant soit pris en main par un pair ? Croyez-moi, j'ai essayé. Mais cela n’a pas fonctionné non plus, car le projet ne pouvait pas se permettre qu’un membre soutienne à mi-temps un collègue.
Nous avancions déjà à toute allure, sans possibilité de ralentir. Les échéances approchaient, la pression montait, la visibilité augmentait, et on attendait de l'équipe qu'elle accélère encore alors que des ressources étaient ajoutées, pas l’inverse.
Au lieu de ralentir, donc, j’ai poursuivi selon le statu quo : à savoir que les nouveaux arrivants au milieu du projet devaient s'accrocher, comme s'ils sautaient dans une voiture lancée à pleine vitesse et mettaient la main sur le moteur brûlant.
Le problème du sentiment d'appartenance
Mais à force de jeter frénétiquement des documents et des invitations à des réunions aux nouveaux venus sur le projet — et à voir l’équipe exécuter mécaniquement les tâches du backlog — une chose est devenue évidente : il ne s'agissait pas d'information. Il s'agissait d'appartenance. Et c'est un état émotionnel qui ne s’acquiert pas uniquement par la documentation.
Je ne pouvais pas donner aux nouveaux membres de l'équipe le sentiment d'appartenance simplement en les rassurant ou en leur parlant plus. Aucun système de parrainage n’allait résoudre ce problème. Aucune réunion « demande-moi tout ce que tu veux » inscrite à l’agenda n’allait tout arranger. Il fallait des espaces sûrs et alternatifs.
Les personnes trouvent leur place différemment selon le contexte : certains veulent du temps calme avec la documentation avant d'échanger avec l'équipe ; certains veulent un parrain ; certains cherchent un endroit sûr pour poser les « questions bêtes » ; et d'autres veulent simplement comprendre le « pourquoi » de la mission et leur rôle dans celle-ci.
C’est là-dessus que j’aurais dû investir mon temps et mon énergie : la création d’un cadre permettant à chaque membre de s’intégrer à sa façon.
Au final, je consacrais trop d’efforts à la cérémonie d’accueil, mais je laissais les arrivées en cours de projet se débrouiller seules.
Ce cycle d’intégration inadéquate ne frustre pas seulement les individus — il met en péril l’ensemble du projet. Quand les nouveaux venus n’arrivent pas à prendre leurs marques rapidement, les décisions prennent du retard, les erreurs se multiplient, et le moral de l’équipe en pâtit.
Et lorsque le changement devient inévitable — quand des membres entrent et sortent à tour de rôle pendant toute la durée du projet — cette approche devient intenable.
Pour les nouveaux membres de l’équipe, le problème n’était pas le manque d’information, d’autorité ou même d’idées. C’était qu’ils n’avaient pas le sentiment d’appropriation.
Une nouvelle façon de concevoir les lancements : l’intégration continue
Alors, quelle est la solution ? Si l’on investit trop dans les lancements et pas assez dans la gestion du changement et l’intégration en cours de projet, comment remettre les choses sur la bonne voie ?
J’avais mes hypothèses, mais j’ai aussi eu un déclic grâce à quelqu’un que j’estime beaucoup, qui m’a dit :
« Je reformule systématiquement l'objectif à presque chaque réunion parce que la ‘bonne étoile’ change sans arrêt. Cela me rappelle comment on s'entraîne au Kung Fu… Il y a un point central sur lequel on se concentre, et tout le reste sert de contexte pour y revenir. C'est une conversation, avec les deux parties qui ‘posent des questions’ et reçoivent des réponses en temps réel par tous les sens. »
Autrement dit, au lieu de compter sur le grand moment du lancement, on peut utiliser chaque interaction pour renforcer l’essence de ce qui compte dans le projet. C’est intégré naturellement à la collaboration, plutôt qu’un grand événement dont on risque d’avoir l’impression de passer à côté si l’on n’a pas pu être présent.
Voici donc ce que j’essaie de mettre en œuvre pour chaque projet depuis :
1. Une politique de documentation légère et facile à mettre à jour
J’ai abandonné mes jolies présentations de lancement et mes artefacts de projet trop soignés (briefs, rapports d’avancement, ordres du jour, logs RAID), et je privilégie désormais des formats faciles à modifier et accessibles aussi bien pour les collègues humains que pour les IA.
Puis je travaille avec les équipes projet pour désigner des responsables de la mise à jour des documents — exactement comme on le fait pour la gestion des risques. Cela répartit la charge et donne à chaque membre le pouvoir de défendre une documentation précise.
Par exemple, nous avons des documents simples et concis dans Notion ou Slite pour les rôles et responsabilités, le brief du projet et les plans de communication. Rien n’est figé dans des tableurs ni des PDF.
2. L'intégration continue comme réalité acceptée
Avec la documentation, j’explique d’emblée à l’équipe que la composition, les objectifs et les modalités du projet peuvent changer du jour au lendemain, et que nous devons être prêts à réagir.
Autrement dit, plutôt que d’espérer que les équipes et les objectifs ne changent pas, on part du principe qu’ils changeront.
Cela signifie qu’il faut éviter au maximum que des informations existent uniquement dans la tête de certaines personnes ou dans des moments précis. Les réunions sont transcrites, les notes d’intervention sont disponibles à l’écrit, la majorité des débats sont menés en canaux publics, et toutes les décisions sont rigoureusement consignées.
Ça permet de garantir que ceux qui n’ont pas vécu le Jour 1 du projet puissent tout de même accéder facilement à l’information dont ils ont besoin. Et cela nous aide aussi à nous adapter comme une nuée d’alouettes si les objectifs ou les circonstances évoluent.
3. L’IA comme source de vérité pour tous les neurotypes
Par ailleurs, mes équipes et moi configurons des chatbots IA ou des bases de connaissances interrogeables dès que possible sur le projet.
Bien souvent, ce n’est pas aussi sophistiqué que ce dont on rêve avec l’IA, mais cela nous rend un service crucial : cela offre un moyen relativement privé, sûr et moins soumis aux jeux de pouvoir pour accéder à l’information du projet — à sa façon, avec la méthode d’apprentissage qui lui convient.
Ces chatbots sont alimentés dès le départ avec des données de projet structurées et non structurées — briefs, SOWs, rapports d’avancement, comptes rendus de réunion et certaines conversations d’équipe. Et comme la documentation est suffisamment légère pour que les membres de l’équipe humaine puissent la tenir à jour, il est relativement facile pour une IA de suivre ce qui a évolué tout au long du projet — décisions prises, budget ajouté, problèmes apparus, risques réalisés, escalades intervenues, etc.
Ce chatbot pourrait alors être interrogé à tout moment par n’importe quel membre de l’équipe, dans un contexte où ils n’ont pas à craindre de paraître stupides et sans avoir besoin de planifier une réunion avec une personne d’autorité déjà surchargée.
Par exemple, un membre de l’équipe peut poser des questions telles que :
- « En quoi ma tâche contribue-t-elle à l’objectif global du projet ? »
- « Qui dépend de moi pour livrer mon livrable à temps ? »
- « Où dois-je enregistrer mes livrables finaux, et quelle est notre convention de nommage des fichiers ? »
Ce sont peut-être des questions auxquelles ils connaissent déjà la réponse, mais ils peuvent vouloir être rassurés quand ils passent d’un projet à l’autre et entre différentes tâches.
Au final, les chatbots IA simplifient le processus d’accès à l’information, augmentant l’efficacité en éliminant le besoin de formation intensive ou de consultations multiples, et améliorent l’accessibilité grâce à une interface conviviale accessible depuis n’importe quel appareil connecté à Internet, 24h/24 et 7j/7.
Mais voici le hic : il est reconnu que l’IA peut se tromper.
Et si elle se trompe, cela peut rapidement faire dérailler un projet. La conséquence globale serait une étape supplémentaire : essayer de questionner le chatbot, examiner la réponse car elle peut être fausse, puis faire appel à son intuition pour décider si l’on suit la réponse reçue sans demander à personne, ou si l’on va voir un collègue — autrement dit, si nous ne faisons pas confiance à l’IA, nous revenons à la case départ.
Il est donc essentiel que les données soient suffisamment fiables pour ne pas être contradictoires. Et ensuite, les humains de l’équipe doivent réellement avoir confiance en leur exactitude (en supposant que nous ne lui ayons pas donné de fausses informations).
Pour garantir cela, notre priorité est d’assurer un maximum d’exactitude, avec des membres clés de l’équipe qui agissent comme ambassadeurs et arbitres de la qualité à travers quelques cas de test et vérifications ponctuelles que nous effectuons régulièrement.
4. Renforcement Rituel des Objectifs
Et pour tout relier, j’essaye d’intégrer certains de mes éléments préférés du lancement de projet malheureusement « unique dans le temps » au quotidien. Par exemple, réitérer et remettre constamment en question la vision produit ou le BHAG pour que la mission soit suffisamment comprise pour être scrutée, et vérifier que l’on construit toujours ce qu’il faut.
Par exemple, j’essaie de rappeler à l’équipe les résultats attendus du projet au début de chaque réunion d’équipe. Quelque chose comme « pour rappel, ce projet vise à permettre aux usagers des transports en commun ayant des capacités différentes de se déplacer plus en sécurité et avec moins de frustration. »
Et si cette Étoile Polaire a changé, j’essaie de le reformuler à chaque réunion ou mise à jour d’avancement : « Pour rappel, ceci a commencé comme une initiative pour les voyageurs en situation de handicap, mais c’est désormais une opportunité d’améliorer l’expérience de tous les clients sur plusieurs réseaux de transport. »
L’autre chose que je fais, c’est utiliser mon rôle de généraliste pour poser des questions qui orientent les décisions en fonction de notre objectif. Par exemple, si l’équipe devait choisir entre deux approches, je demanderais : « laquelle nous aidera à éliminer le plus de friction dans l’expérience client ? »
Pour ce qui est des valeurs d’équipe et des modes de fonctionnement, je préfère conclure les réunions par un rappel : « N’oubliez pas de garder les communications importantes dans le canal partagé, si elles peuvent aider les autres à faire leur travail. »
Non seulement cela aide les personnes qui rejoignent le projet en cours de route à ne pas avoir l’impression d’avoir manqué quelque chose au début, mais cela permet aussi de renforcer continuellement la mission auprès de tous les acteurs impliqués.
5. Une Culture d’Appartenance
Mais surtout, j’essaie de changer mon état d’esprit de « transfert de connaissances » à « transfert de responsabilité » en privilégiant des moyens d’aider les nouveaux membres de l’équipe ou parties prenantes à se sentir « chez eux » dans le projet et à pouvoir y apporter tout leur potentiel.
À mon avis, il n’y a pas de méthode unique ou infaillible pour y parvenir, mais je suis convaincu que la solution n’est pas de surcharger d’informations les gens. Nous, humains, devons utiliser notre humanité pour répondre à ce qui relève uniquement de l’humain : émotions, égo, communauté et sens.
Lorsque les gens ne se sentent pas propriétaires, ils sont moins enclins à s’exprimer lorsqu’un détail semble problématique ou à remettre en question une décision qui pourrait faire déraper le projet.
Pourquoi c’est plus important que jamais
Aujourd’hui, je constate que le problème de l’intégration en cours de projet devient de plus en plus important. Les membres de ma communauté pilotent des projets marqués par un va-et-vient permanent de spécialistes à temps partiel, de freelances, et même de salariés déplacés sans cesse d’un projet à l’autre pour maintenir leur activité.
En parallèle, les outils d’IA créent des attentes mouvantes chez les parties prenantes des projets : on s’attend à ce que les projets avancent plus vite, qu’ils gèrent mieux le changement, et qu’ils génèrent plus de valeur en exploitant les données, l’automatisation et la prise de décision autonome.
Autrement dit, les équipes sont plus volatiles et le rythme s’accélère. Cela signifie que l’écart en termes de sentiment d’appartenance s’agrandit, alors que tout bouge et change beaucoup plus vite.
Et voici le vrai risque : nous ne voulons pas simplement réaliser la mauvaise chose plus rapidement.
Lorsque les gens ne se sentent pas impliqués, ils sont moins enclins à s’exprimer lorsqu’un détail semble problématique ou à remettre en question une décision qui pourrait faire dérailler le projet.
Voilà pourquoi l’intégration continue n’est plus une option. Ce n’est pas un bonus ou une compétence douce. C’est un impératif pour l’entreprise. Si nous voulons des équipes capables de s’adapter et d’apporter une réelle valeur ajoutée dans cet univers de projets plus rapides et plus fragmentés, il nous faut des personnes qui se sentent investies dans la vision, pas seulement informées des tâches.
Alors, les kickoffs sont-ils dépassés ?
Les lancements de projet ne sont certainement pas dépassés. Ni pour moi, ni pour de nombreuses équipes.
Personnellement, je les adore. Je pense que les kickoffs de projet sont des rassemblements capables de créer des liens entre les personnes et d’offrir des forums de dialogue à un moment crucial du cycle de vie du projet. Je les trouve profondément humains. Donc oui, je continue les kickoffs, et il faudra me les arracher des mains !
Ce que je fais différemment, c’est que je ne place plus tous mes espoirs et mes rêves dans ces kickoffs. Je n’investis plus autant d’énergie à rendre le lancement parfait, spectaculaire et théâtral. Je n’aspire plus à en faire la cérémonie ultime qui donnerait aux nouveaux arrivants le sentiment d’être des membres de second rang s’ils n’étaient pas là au début. Et je ne cherche surtout pas à en faire quelque chose qui nous enfermerait dans l’idée d’un parcours unique et immuable.
Parce qu’un projet n’est jamais une ligne droite. C’est un cerf-volant dans le vent, qui bouge, qui tangue, et qu’on doit sans cesse ajuster, quoi qu’il se passe. Le changement est inévitable. C’est donc à cela que nous devrions consacrer notre énergie préparatoire.
Qu’en pensez-vous ?
Mais j’aimerais aussi avoir votre avis : les kickoffs sont-ils vraiment aussi problématiques que je l’ai laissé entendre ? Comment abordez-vous l’intégration sur vos projets – surtout lorsque des membres rejoignent en cours de route ?
