Le kick-off viable : la fiche que j’aurais aimé avoir

Suite du kick-off raté. Cette fois, on part avec une carte, une boussole, et quelqu’un a pensé aux chaussures.

Il y a quelque temps, j’ai raconté deux kick-offs ratés en trois semaines. Le premier, fourre-tout : trois projets en un, aucun besoin finalisé, et moi pressenti comme PO, business owner, architecte et développeur. Il ne manquait plus que responsable de la machine à café pour compléter la fiche de poste. Spoiler: un an plus tard, je n’en ai plus jamais entendu parler. Je suppose que le projet a été lancé très loin. Peut-être même en orbite.

Le second était plus subtil. Pas de présentation du projet, pas de support, personne pour véritablement prendre le lead, mais une ambiance suffisamment glaciale pour conserver des surgelés. En revanche, les questions étaient bien présentes : quel planning ? Quelle organisation ? Quels points de suivi ? Quel tableau de bord ?
Autrement dit, on me demandait de produire tout ce que l’organisateur de la réunion aurait normalement dû préparer.

Je terminais cet article sur une question : est-ce que je veux vraiment ce rôle ?

Récemment, en commençant une nouvelle mission d’architecture, on m’a demandé de préparer un kick-off. J’ai retrouvé cette petite sensation familière, entre la méfiance et la résignation. Celle qu’on éprouve quand on comprend que le projet n’a pas encore démarré, mais que certaines responsabilités ont déjà trouvé leur propriétaire.

Cette fois, j’ai décidé de ne pas arriver les mains dans les poches.

J’ai préparé une présentation. Et, tant qu’à faire, une fiche réutilisable.

Le recovery, ou l’archéologie avec une date de livraison

On ne fait pas de l’architecture, on fait des fouilles. Il ne manque que le pinceau et le chapeau.

Un dossier d’architecture de recovery, c’est reconstituer l’architecture d’une application qui existe déjà. Elle tourne. Elle est en production. Des gens l’utilisent tous les jours. Simplement, les procédures de l’entreprise n’ont pas été suivies lors de sa création, et pour demander du budget pour une évolution, il faut repartir sur de bonnes bases…

On démarre donc souvent avec :

• un développeur d’origine parti élever des chèvres dans le Larzac en 2012, avec le mot de passe admin ;
• peu de documentation fiable ;
• des acteurs dispersés ;
• des responsabilités floues ;
• une application en production qu’il ne faut surtout pas casser en la regardant ;
• et beaucoup de gens persuadés que « quelqu’un doit bien avoir des docs quelque part ».

Spoiler : non.

L’objectif n’est pas de redocumenter pour faire joli. Non, cette fois-ci, vu que les décideurs savent maintenant qu’ils ont foiré quelque part, il faut bien repartir pour montrer que l’on tient le projet bien en main. Il faut donc reconstituer une vision exploitable de l’existant, pour sécuriser les évolutions, l’exploitation, la conformité et les décisions futures.

Et c’est précisément pour ça que le kick-off compte encore plus que d’habitude. Sur un projet neuf, un démarrage flou produit un projet flou. Sur un recovery, un démarrage flou produit… le même flou qu’avant, mais avec un dossier d’architecture en plus.

Un kick-off, ça sert à quoi (vraiment) ?

Je me pose parfois la question quand je vois le nombre de réunions de lancement organisées dans les entreprises. Un kick-off ne sert pas à faire un lancement officiel. Il sert à rendre le démarrage opérable.

Oui, les choses sont décidées avant, c’est vrai, mais encore faut-il les avoir partagées. Avez-vous remarqué que l’on attend beaucoup que les informations remontent vers la direction mais que les décisions ont de plus en plus de mal à redescendre, malgré la prolifération des outils ?

Les décisions ont du mal à descendre, mais les responsabilités, elles, descendent très bien. C’est la seule théorie du ruissellement qui fonctionne vraiment : en haut on décide, au milieu on délègue, et tout en bas, il y a l’architecte qui doit sortir une boule de cristal.

Bref, à la fin, on doit avoir validé :

• pourquoi on lance ce travail ;
• ce qu’on attend concrètement en sortie ;
• qui fournit quoi ;
• dans quels délais ;
• selon quel mode de fonctionnement ;
• avec quelles limites.

Pour un recovery, il y a une subtilité. Le but n’est pas de faire semblant d’avoir déjà compris le système. Le but est de poser un cadre de collecte, d’analyse et de validation. On ne présente pas une solution, on organise une enquête.

Ce qu’il faut vraiment cadrer

Le contexte

Il faut savoir pourquoi on est là. Cela semble évident, mais j’ai déjà vu des réunions où les participants ne partageaient même pas la même compréhension de l’objectif. Certains attendaient un dossier d’architecture, d’autres une étude de modernisation, et quelques-uns espéraient probablement une migration complète en prime.

C’est donc l’application ou le périmètre concerné, la raison du recovery, le niveau de connaissance actuel, le problème de départ. Une phrase comme « reconstituer une vision exploitable de l’architecture existante afin de sécuriser les évolutions » vaut mieux que dix slides d’historique.

Le périmètre, et le hors périmètre

C’est le point le plus souvent oublié. Il faut dire ce qui est inclus, ce qui ne l’est pas, et ce qui sera étudié si nécessaire, sans garantie initiale.

Sans ça, le recovery devient une partie de jeu de rôle. On commence avec une mission raisonnable, puis le Maître du Donjon ajoute de nouvelles quêtes à chaque réunion. Au bout de trois semaines, on doit cartographier une application inconnue, analyser toutes ses interfaces et résoudre un problème réseau vieux de quinze ans.

Les rôles et responsabilités

Oui, il faut les mettre. Mais pas en mode décoratif, avec une jolie grille de logos.

Au minimum : sponsor ou demandeur, coordinateur, architecte, experts applicatifs, experts infrastructure, sécurité, exploitation, et métier si nécessaire. Et surtout, préciser qui valide, qui fournit les informations, qui arbitre, qui est consulté, et qui est simplement informé.

Un mini RACI, même simple. Même sur un coin de slide.

Les entrants attendus

Il ne suffit pas de demander des documents. Il faut identifier les personnes capables de les fournir, vérifier qu’elles sont disponibles et convenir d’un délai.

Sinon, trois semaines plus tard, on découvre qu’un document est probablement archivé dans un ancien espace SharePoint auquel personne n’a accès, sauf Gérard, qui est à la retraite depuis 2019.

Pour un recovery, c’est le cœur du sujet. Il faut lister noir sur blanc ce dont on a besoin :

• documents existants et schémas, même anciens ;
• accès aux environnements ;
• liste des applications connexes ;
• inventaires techniques, références de serveurs ou de clusters ;
• contacts des experts ;
• contraintes sécurité et réseau ;
• éléments d’exploitation.

Sans cette liste, on vous demandera ensuite de « faire parler l’existant ». Mais un système programmé en douce et mis en production ne parle pas, il se cache.

Les livrables

Pas seulement leur nom. Leur niveau de détail, leur statut attendu, ce qui sera validé et ce qui restera à confirmer.

Par exemple : dossier d’architecture de recovery en version initiale, fondé sur les éléments disponibles, avec les hypothèses, les zones d’incertitude et les points à confirmer explicitement tracés.

Ça évite les phrases comme : « Comment ça, on n’est pas onboardé sur Checkmarx alors que l’application tourne depuis 2004 ? »

Ben oui, justement. Elle tourne depuis 2004. Checkmarx n’existait pas… Et puis, il faut des sous…

Entre-temps, les outils, les standards et les exigences de sécurité ont évolué. Et, détail parfois oublié, mettre un existant en conformité demande du travail, du temps et généralement un budget.

Les jalons

Avec leurs conditions de réussite : dates cibles, dépendances, contributions attendues, risques de décalage. Un jalon sans prérequis, c’est juste une date optimiste.

Les hypothèses et les limites

À dire dès le départ, et à voix haute : le dossier sera construit à partir des informations disponibles, et sa précision dépendra directement de la qualité et de la disponibilité des sources.

Ce n’est pas se couvrir. C’est poser le contrat.

Les risques

Pour un recovery, on les connaît d’avance :

• documentation absente ou obsolète ;
• experts indisponibles ;
• périmètre mouvant ;
• confusion entre architecture cible et architecture existante ;
• attente implicite d’exhaustivité immédiate ;
• validation tardive.

Les nommer au kick-off, ce n’est pas faire peur. C’est éviter les faux étonnements trois semaines plus tard.

Dire « nous risquons de manquer d’informations sur certaines interfaces » au démarrage permet de rechercher les bons interlocuteurs.

Le découvrir six semaines plus tard, au moment de la validation, transforme le même sujet en problème de planning, puis en sujet d’escalade, et parfois en réunion avec des gens qu’on n’avait jamais rencontrés auparavant.

Le risque est le même. Son prix a simplement changé.

Le mode de fonctionnement

Fréquence des points, canal de communication, gestion des questions, circuit de validation, compte rendu ou non, et surtout : qui décide en cas de blocage. Et non, l’architecte peut donner ses disponibilités, l’architecte peut dire quand il communique, mais il ne peut pas être de toutes les réunions de suivi, sinon il n’a plus le temps d’avancer dans son travail.

Parce que « on verra plus tard » est une très belle phrase. C’est aussi l’une des plus destructrices du vocabulaire projet.

Ce qui manquait à mon propre support

Bien, je m’étais fait avoir une fois, et je déteste cela.

Je suis stressé même quand avec une préparation, alors cette fois-ci, j’ai essayé de me blinder.

Ma première version de présentation était correcte. Contexte, hypothèses, périmètre, hors périmètre, entrants, acteurs, livrables, planning. Propre.

Et pourtant, il lui manquait quand même les risques.

Le problème, c’est qu’on ne se rend pas compte des manques en préparant les slides. On s’en rend compte six semaines plus tard, quand quelqu’un demande pourquoi l’interface avec une obscure application (qui n’existe pas officiellement non plus) n’est pas documentée, alors que personne n’en avait jamais parlé.

Qui doit organiser le kick-off (ou qui va attraper la patate chaude) ?

C’est la question qui me travaillait depuis mes deux naufrages.

— Tu pourras préparer un petit support pour le kick-off ?
— Bien sûr. Je présente quoi ?
— Ben… le projet.
— Celui que je découvre ?

Je caricature un peu, mais à peine.

Ce n’est pas l’architecte. Oui, je peux faire une réunion de cadrage qui va donner des éléments au kick-off. Pour le reste, ce n’est pas moi. Mais pourquoi ?

Parce que j’arrive sur le projet, je ne connais pas les sachants, je ne connais pas le planning, je ne connais pas l’organisation du projet…

Mais ici, l’hypothèse implicite de mon client était : puisque l’architecte produit le dossier, il va convoquer, cadrer, préparer, présenter et animer.

Ce n’est pas mon avis. Dans une organisation qui fonctionne :

• le sponsor ou le porteur du besoin légitime le lancement ;
• le chef de projet, le coordinateur ou le commercial, selon les cas, mobilise les acteurs ;
• l’architecte apporte le fond, le cadre technique et la liste de ce dont il a besoin.

Dans un monde bien organisé, l’architecte n’est donc pas automatiquement l’orchestre, le chef d’orchestre, le régisseur et la billetterie.

En revanche, dans la réalité, lorsque personne ne prend l’initiative, il arrive que celui qui veut avancer finisse par le faire. Parce qu’au bout d’un moment, il faut choisir entre défendre un principe et faire démarrer le travail. Et comme dit mon psy : il faut choisir ses combats.

Et parce que les incompréhensions se retournent parfois contre celui qui était censé produire le livrable. Je connais cette situation où le client exprime son insatisfaction auprès de la hiérarchie, alors que certains éléments nécessaires à la mission n’ont jamais été clarifiés.

À la fin, l’histoire peut devenir très simple : l’architecte n’a pas suffisamment cadré son intervention.

Le reste disparaît dans les comptes rendus.

C’est aussi pour cela que je prépare davantage les choses aujourd’hui. Pas pour prendre systématiquement la place des autres, mais pour être capable de montrer ce que j’ai proposé, demandé et signalé.

Vous savez quoi ? Aujourd’hui encore, j’avais une réunion de lancement, je me suis préparé, j’ai fait une présentation… Cette fois-ci, le client avait pris les devants et animait la réunion. Mais il n’avait pas préparé de présentation. J’ai donc sorti la mienne et on a mieux cadré la réunion. Je n’ai pas senti de surprise chez mon client, mais ce qu’il racontait était écrit et il a donc pu constater que j’avais anticipé.

La présentation de secours, c’est comme le parapluie : quand on l’a, il ne pleut pas. Quand on l’oublie, c’est la mousson, et en plus on se fait convoquer.

La position que je retiens :

• je peux contribuer à la réunion ;
• je peux coanimer ;
• je peux fournir le support ;
• mais je n’absorbe pas silencieusement tout le rôle de lancement si ce n’est pas le mien.

Le mot important, c’est silencieusement. Faire le travail d’un autre, parfois, c’est la vie. Le faire sans que ce soit visible, c’est créer une habitude, et l’habitude finit par devenir une fiche de poste.

Préparer, ce n’est pas faire le travail des autres. C’est avoir la preuve que j’ai fait le mien.

La fiche : six slides, pas une de plus

30 à 45 minutes de présentation et de discussion, puis les questions.

L’idée est de disposer d’un support que je peux adapter à chaque mission, suffisamment complet pour ne pas oublier les sujets importants, mais assez léger pour permettre la discussion. Ce n’est pas un modèle universel. C’est une base adaptable. Certaines missions nécessiteront davantage de détails, d’autres beaucoup moins.

Le vrai indicateur de réussite, ce n’est pas que les slides soient passées. C’est qu’à la fin, chacun sait ce qu’il doit fournir, les règles de fonctionnement sont claires, le prochain pas est daté, et les blocages sont identifiés.

Slide 1 – Contexte et objectif

Pourquoi ce recovery est lancé. Ce que la mission doit permettre.

Slide 2 – Périmètre

Inclus. Exclus. Interfaces et sujets connexes. Hypothèses de départ.

Slide 3 – Acteurs et responsabilités

Sponsor, contributeurs, validateurs, interlocuteurs clés. Le mini RACI.

Slide 4 – Entrants attendus

Documents, accès, contacts, informations techniques, éléments d’exploitation.

Slide 5 – Jalons et livrables

Grandes étapes, dates cibles, dépendances majeures, niveau de validation attendu.

Slide 6 – Risques, règles du jeu et prochaines étapes

Limites connues, mode de fonctionnement, premier lot d’actions.

La réunion est terminée. Maintenant, le vrai travail commence.

J’ai également ajouté un point que je considère désormais comme indispensable : la sortie de réunion. À la fin du kick-off, on doit pouvoir répondre oui à ces questions :

• Objectifs : le besoin et les résultats attendus sont-ils compris ?
• Périmètre : les limites et les hypothèses sont-elles explicites ?
• Responsabilités : les contributeurs, les décideurs et les validateurs sont-ils identifiés ?
• Informations : sait-on quels documents, accès et contributions doivent être fournis, par qui et quand ?
• Livrables et jalons : les attendus, les échéances et les modalités de validation sont-ils clairs ?
• Risques : les principaux points de vigilance ont-ils été partagés ?
• Suite : les premières actions sont-elles attribuées, datées et suivies ?

Si la réponse est non à plusieurs de ces questions, ce n’est pas un kick-off viable. C’est une réunion d’introduction avec support PowerPoint. Ce n’est pas la même chose.

Une chose importante : on envoie un compte rendu. S’il n’y a pas de retour, on aura une preuve. Et c’est souvent nécessaire.

Le compte rendu, c’est l’assurance tous risques de l’architecte : on râle en payant la cotisation, et on est bien content le jour du sinistre.

Conclusion : un contrat de départ

Un kick-off viable répond à une question simple : comment va-t-on produire quelque chose d’exploitable, avec qui, sur quelle base, et dans quelles limites ?

S’il n’y répond pas, ce n’est pas un kick-off. C’est un échauffement sans match derrière.

L’an dernier, je me demandais si je voulais vraiment ce rôle d’homme-orchestre. Je n’ai toujours pas envie de le jouer.

Avec les années, j’ai compris qu’on ne pouvait pas toujours corriger l’organisation d’un projet. On peut en revanche éviter d’ajouter du désordre au désordre.

Je ne suis toujours pas convaincu que l’architecte doive organiser tous les kick-offs. Mais je sais maintenant que je peux arriver avec les bonnes questions, les bons documents et une idée claire de ce qu’il faut obtenir de la réunion.

Je ne fais pas forcément le travail des autres. Je leur donne aussi une chance de faire le leur.

Et si, pour une fois, tout le monde repart avec les mêmes objectifs, les mêmes responsabilités et les mêmes échéances, on aura déjà fait mieux que lors de bien des lancements.

Ce n’est peut-être pas spectaculaire. Il n’y aura probablement pas de trophée.

Mais un projet qui démarre correctement, en informatique, mérite presque une cérémonie.

Maintenant, j’ai une base réutilisable et je ne suis pas pris au dépourvu.

Le kick-off n’est pas un cérémonial. C’est un contrat de départ. Et comme tout contrat, mieux vaut l’avoir préparé soi-même… et en avoir gardé une copie.

Au fait, vous avez bien pensé à inviter le chef de projet ?