Ces projets qu'il vaudrait mieux arrêter avant même de les lancer
Équipe mal constituée, direction absente, périmètre démesuré : certains projets cumulent les risques avant même leur lancement. Parfois, ne pas les lancer est la meilleure décision.
Certains projets ne devraient pas être lancés.
La phrase dérange, car dans beaucoup d’organisations, lancer un projet est déjà considéré comme une forme de réussite. Le budget a été obtenu, l’équipe commence à se réunir et une date de kickoff est annoncée. La machine est en marche.
Pourtant, un lancement ne corrige pas les fragilités présentes en amont. Il ne fait souvent que les rendre plus coûteuses.
Il n’est évidemment pas possible de prédire systématiquement l’avenir d’un projet. Mais il est parfois possible de détecter, avant son démarrage, que plusieurs conditions essentielles ne sont pas réunies.
L’équipe n’est pas adaptée. Les responsabilités sont floues. La direction observe le projet de loin. Le périmètre est disproportionné. Les hypothèses techniques n’ont jamais été testées et les informations circulent déjà difficilement.
Pris séparément, ces problèmes peuvent être corrigés. Lorsqu’ils s’accumulent et que personne ne souhaite les traiter, le lancement du projet ressemble moins à une décision qu’à un acte de foi.
Une équipe sur le papier ne suffit pas
Le premier signal concerne le staffing.
Un projet ne réussit pas simplement parce qu’une liste de personnes a été associée à son organigramme. Il faut réunir les compétences nécessaires, mais aussi les bons comportements et le bon état d’esprit.
Une addition d’experts ne constitue pas automatiquement une équipe.
Des collaborateurs très compétents peuvent échouer à travailler ensemble s’ils ne partagent pas les informations, défendent uniquement leur périmètre ou attendent qu’un problème soit officiellement attribué avant de s’en saisir.
À l’inverse, une équipe capable de réfléchir collectivement, de challenger une idée sans bloquer la discussion et de débloquer rapidement des sujets complexes peut compenser certaines lacunes individuelles. La capacité à trouver ensemble une solution a parfois plus de valeur que l’expertise isolée de chaque participant.
Le bon état d’esprit ne signifie pas que tout le monde doit être d’accord ou entretenir une convivialité de façade. Il désigne la capacité à avancer ensemble, à demander de l’aide, à signaler une erreur et à chercher une solution plutôt qu’un responsable.
Les travaux menés par Google dans le cadre du projet Aristotle ont notamment montré que, pour prédire l’efficacité d’une équipe, la manière dont ses membres interagissent compte davantage que sa composition. La sécurité psychologique, qui permet de poser des questions, de proposer des idées et de reconnaître des erreurs sans crainte, apparaît comme la dynamique la plus importante.
Cette clarté doit exister avant le lancement. Chacun doit savoir qui pilote le projet, qui arbitre les priorités, qui valide le produit, qui engage la responsabilité technique et qui peut réellement lever un blocage.
Si obtenir une décision nécessite déjà de multiplier les relances et de remonter une chaîne de validation interminable, le projet consommera une grande partie de son énergie à lutter contre sa propre organisation.
La qualité de l’équipe dépend également de la place laissée à la direction.
Il ne s’agit pas de demander au directeur général ou au sponsor d’assister à toutes les réunions. Sa présence permanente deviendrait probablement contre-productive. Il doit en revanche intervenir là où son regard est irremplaçable.
Les dirigeants disposent d’une perception particulière de l’entreprise, du marché et de la stratégie. Leur niveau d’abstraction leur permet parfois de poser une question ou de formuler un simple commentaire qui remet complètement le projet sur les rails.
Encore faut-il que cette intervention arrive au bon moment.
Un dirigeant ne peut donc pas se limiter à relever les compteurs une fois par mois en demandant si le planning et le budget sont toujours respectés. Il fait partie de l’équipe, même si sa contribution intervient à des moments précis.
Son rôle est de protéger la priorité du projet, de rappeler son intention initiale et d’aider l’équipe à résoudre les problèmes qui dépassent son niveau de responsabilité.
Une étude du Project Management Institute constatait que 76% des projets bénéficiant du soutien d’un sponsor exécutif atteignaient leurs objectifs, contre 46% en l’absence de ce soutien.
Si personne ne souhaite réellement tenir ce rôle, il faut s’interroger sur l’importance accordée au projet avant de le lancer.
La technologie et l’ambition doivent rester au service de l’apprentissage
Un projet IT ne peut pas être piloté durablement en considérant la technologie comme une boîte noire réservée aux développeurs.
Les décideurs n’ont pas besoin de maîtriser le code ou le détail de l’architecture. Ils doivent en revanche rester curieux, comprendre les possibilités et questionner les contraintes présentées comme immuables.
Le monde technologique évolue trop rapidement pour construire un projet uniquement à partir des certitudes acquises lors des expériences précédentes.
L’intelligence artificielle s’est installée dans les usages quotidiens. De nouveaux outils apparaissent continuellement. Des opérations qui nécessitaient plusieurs semaines peuvent parfois être testées ou prototypées en quelques jours.
Cela ne signifie pas qu’il faille courir après chaque nouveauté. Il faut plutôt créer, dès le départ, un espace permettant d’expérimenter et de rechercher des gains rapides.
Une preuve de concept peut tester une API, la qualité des données ou une automatisation avant d’engager plusieurs mois de développement. Ces quick wins produisent rapidement de l’information et réduisent les incertitudes.
La technologie ne sauvera cependant jamais une organisation mal préparée. Le rapport DORA 2025 présente notamment l’intelligence artificielle comme un amplificateur. Elle renforce les qualités des organisations performantes, mais peut également amplifier les faiblesses des équipes dont les processus ou les responsabilités sont mal structurés.
L’autre danger consiste à voir trop grand.
Plus le premier objectif est vaste, plus le projet accumule de dépendances, de besoins, d’interlocuteurs et de scénarios à anticiper. Chaque élément supplémentaire augmente le nombre de points de défaillance possibles.
Une ambition importante n’impose pourtant pas une première livraison gigantesque.
De petites équipes parviennent régulièrement à prendre position sur des marchés occupés par de grands acteurs. Leur avantage ne vient pas de leur capacité à fournir davantage de travail. Elles apprennent souvent plus rapidement parce qu’elles avancent par étapes courtes.
Elles livrent une première proposition, observent son utilisation, récupèrent des retours et adaptent leur trajectoire. Le coût de chaque erreur reste ainsi limité.
Les principes du Manifeste agile recommandent une livraison fréquente de logiciels fonctionnels. Les recherches de DORA sur le travail en petits lots associent également cette pratique à de meilleures performances de livraison et d’organisation.
Une première version réduite permet de vérifier que le besoin est correctement compris, que la solution technique fonctionne, que les utilisateurs y trouvent une valeur réelle et que la poursuite de l’investissement reste justifiée.
À l’inverse, une approche big bang concentre les risques et retarde le retour du terrain jusqu’au moment où une part importante du budget est déjà consommée.
Lorsqu’il est impossible de définir une première étape maîtrisable, le périmètre doit être revu avant le lancement.
Le temps gagné en amont n’est pas du temps perdu
Un autre signal apparaît lorsque la date de développement est annoncée avant que les principales incertitudes soient levées.
Préparer un projet ne signifie pas produire des centaines de pages de documentation ou chercher à anticiper chaque événement. Il s’agit de consacrer suffisamment de temps à la conception pour éviter de découvrir les problèmes les plus structurants pendant l’exécution.
Les parcours, les flux de données, les interfaces, les dépendances, les contraintes de sécurité et les conditions de mise en production doivent être suffisamment compris.
Il faut également clarifier les critères d’acceptation, les responsabilités, l’organisation du support et les solutions de repli en cas de problème.
Un prototype ou un test technique réalisé en amont coûte presque toujours moins cher qu’une remise en question fondamentale au milieu des développements.
Une équipe qui déroule rapidement n’est pas nécessairement une équipe qui développe vite. C’est souvent une équipe qui a suffisamment préparé le terrain pour avancer avec moins d’incertitudes.
Si le planning repose encore sur des hypothèses majeures que personne n’a eu le temps de vérifier, lancer l’exécution ne les fera pas disparaître.
La même exigence doit s’appliquer à la communication.
Un projet transverse ne peut pas fonctionner si l’information reste enfermée dans des silos. Une information connue d’une seule personne, mais nécessaire à toute l’équipe, se comporte presque comme une information inconnue. Elle ne peut pas être intégrée aux décisions, à la planification ou à l’évaluation des risques.
La communication doit être transverse, transparente, simple et régulière.
Cela ne signifie pas qu’il faille mettre toute l’entreprise en copie de chaque message ou organiser une réunion quotidienne avec toutes les parties prenantes.
L’équipe doit simplement disposer d’un espace de référence accessible, de responsabilités visibles, de décisions tracées, de risques partagés suffisamment tôt et de prochaines étapes clairement attribuées.
La transparence doit également permettre de signaler une difficulté sans craindre d’être immédiatement désigné comme coupable.
Lorsque les mauvaises nouvelles commencent à être filtrées, retardées ou reformulées pour préserver un indicateur, le pilotage repose rapidement sur une représentation du projet qui n’existe plus.
Si la communication est déjà laborieuse avant le démarrage, elle le deviendra encore davantage lorsque les premières urgences apparaîtront.
Parfois, la meilleure décision est un no go
Aucun projet ne démarre avec des conditions absolument parfaites. Attendre la disparition de chaque risque reviendrait à ne jamais rien entreprendre.
Le véritable signal d’alerte apparaît lorsque plusieurs faiblesses importantes s’accumulent et que personne ne souhaite les traiter.
L’équipe n’est pas prête. Le sponsor reste à distance. Les hypothèses techniques ne sont pas testées. Le premier périmètre est trop large. La conception est incomplète et la communication fonctionne déjà mal.
Dans ces conditions, maintenir le kickoff à tout prix ne relève plus de l’ambition. C’est accepter consciemment un niveau de risque très élevé.
Arrêter le lancement peut alors signifier organiser une phase de conception, réduire le périmètre, compléter l’équipe, clarifier la gouvernance ou résoudre une dépendance critique.
Dans certains cas, cela peut aussi conduire à abandonner définitivement une initiative dont la valeur ne justifie plus les risques.
Ce n’est pas nécessairement un échec.
Les projets mal engagés ne consomment pas seulement du budget. Ils usent les équipes, provoquent du turnover et détériorent la confiance accordée aux initiatives suivantes.
Le courage managérial ne consiste donc pas toujours à lancer. Il consiste parfois à prononcer un "no go" tant que les conditions minimales ne sont pas réunies.
Parfois, le premier succès d’un projet consiste simplement à ne pas le lancer.