Partie 4 — Obtenir l'accord
Le business case d'une page
Quatre cents à cinq cents mots. Deux minutes de lecture. Si une phrase n’aide personne à décider, coupez-la — architecture du modèle, noms de fournisseurs, détail des API et plan de projet vivent tous dans une annexe que la plupart des dirigeants n’ouvriront jamais.
Les cinq blocs
| Bloc | Ce qu’il contient |
|---|---|
| 1. Le problème | Précis et mesurable — volume, temps, coût, ou un KPI qui a évolué dans le mauvais sens. « Nous voulons être plus innovants » est une aspiration, pas un problème. |
| 2. La solution proposée | Ce qu’elle fait, en langage métier. Pas l’architecture, pas le fournisseur, pas le modèle. Ce qui change dans le processus, et pour qui. |
| 3. L’impact attendu, avec des chiffres | Commencez par le chiffre phare, puis le détail qui l’étaye. Utilisez le scénario conservateur de la partie 3, jamais l’optimiste. Reliez-le à une priorité que l’entreprise a déjà. |
| 4. Les risques et leur atténuation | Nommez-les, à partir du canevas de la partie 1. Ignorer un risque ne le supprime pas — cela dit au lecteur que vous n’y avez pas pensé. Une ligne d’atténuation chacun. |
| 5. Le plan de mise en œuvre | À haut niveau, avec un point de décision. La direction doit savoir ce qu’elle approuve, et quand elle saura si cela a fonctionné. |
Le même projet, écrit de deux façons
Rien dans ce qui suit n’est techniquement faux. C’est exactement le problème de la seconde version.
La version qui est approuvée
Le problème. Notre équipe de support client traite 5 000 tickets par mois avec un temps de réponse moyen de 24 heures. La satisfaction a chuté de 15 points sur l’année écoulée à cause des longs temps d’attente. L’équipe est à saturation et ne peut absorber la croissance projetée de 40 % sur les 12 prochains mois sans embauches importantes.
L’impact, avec des chiffres. 300 000 $ de bénéfice annuel net, 214 % de ROI, récupéré en 5,6 mois. Traiter 7 000 tickets par mois avec l’équipe existante, contre 5 000 aujourd’hui. Réduire les erreurs et les reprises de 8 % à 3 %. Éviter l’embauche de quatre agents supplémentaires.
Point de décision. Passer au déploiement complet uniquement si le pilote atteint un taux d’automatisation de 50 % et maintient des scores de qualité au-dessus de 4,0 sur 5,0.
Un directeur financier qui ne lit que la première ligne du bloc impact connaît déjà la réponse. Les chiffres viennent directement du calcul en quatre étapes de la partie 3, et c’est ce qui les rend défendables sous les questions.
La version qui est classée sans suite
« Nous proposons de mettre en œuvre un grand modèle de langage à base de transformers à la pointe, affiné sur nos données de support client selon une architecture de génération augmentée par récupération, intégré à notre CRM existant via des API REST et déployé sur des clusters à mise à l’échelle automatique pour garantir une haute disponibilité et une faible latence. »
Deux cents mots sur l’architecture avant que le lecteur n’apprenne pourquoi il devrait s’y intéresser. Ce qui suit n’est pas mieux : des métriques techniques sans rien sur le coût ou la capacité, un chiffre de coût sans rendement à côté, et une conclusion qui réclame de l’urgence au lieu de proposer un plan. Rien ici n’est factuellement faux. C’était simplement écrit pour un lecteur technique, et la personne qui signe le budget n’en est pas un.
Les cinq choses qui manquent à la version qui échoue
- Pas de problème métier clair — l’équipe est-elle débordée, les clients attendent-ils, les coûts sont-ils trop élevés ? Le lecteur ne l’apprend jamais.
- Pas de KPI métier — l’exactitude et le score F1 sont le langage de l’équipe data. La satisfaction, le coût et la capacité sont celui du décideur.
- Pas de calcul de ROI — un chiffre de coût sans rendement attaché n’est qu’un chiffre qu’on réclame.
- Pas d’analyse des risques — faible adoption, mauvaise qualité des données, dépassement de l’intégration. Tous réels, aucun reconnu, alors le lecteur suppose qu’ils n’ont pas été considérés.
- Pas de plan ni de critères de succès — quand jugera-t-on que la phase 1 a fonctionné, et que se passe-t-il sinon ?
Utilisez cette liste comme check-list avant d’envoyer quoi que ce soit, pas comme un avertissement après coup.
Trois vérifications avant d’envoyer
- Quelqu’un qui n’a jamais entendu parler de ce projet pourrait-il expliquer le problème après avoir lu le seul bloc un ?
- Le chiffre du bloc trois est-il le scénario conservateur de la partie 3, et non l’optimiste ?
- Y a-t-il, dans le bloc cinq, une date à laquelle quelqu’un saura si cela a fonctionné ?
Si l’une de ces trois vérifications échoue, le document n’est pas prêt — aussi bon que soit le projet sous-jacent.