Modèle de collecte des exigences : mes 7 astuces

Un modèle de collecte des exigences ne mérite sa place que s'il force les conversations difficiles dès le départ : qui signe, qui peut bloquer, à quoi ressemble le succès et quelle doit être la rapidité du système. Ce guide s'adresse aux chefs de projet, aux analystes métier et aux responsables SAP qui ont besoin d'un modèle qui tient au-delà du premier comité de pilotage. Vous trouverez ci-dessous le plan complet que j'utilise, avec un responsable pour chaque section, les cinq sections que je ne saute jamais et sept astuces pour les entretiens, la priorisation et le changement. Recopiez ce plan dans votre propre document et remplissez-le avant le début de la conception.

J'ai vu un jour un projet à six chiffres imploser parce que personne n'avait fait correctement le travail sur les exigences. Le client attendait une chose. L'équipe de développement en a construit une autre. Tout le monde s'est retrouvé sacrifié, et c'est à ce moment-là qu'on m'a appelé.

Ce schéma n'a rien d'exceptionnel. Le rapport Pulse of the Profession 2014 du PMI sur la gestion des exigences a constaté que 47 % des projets en échec n'avaient pas atteint leurs objectifs à cause d'une mauvaise gestion des exigences. Je l'ai vu se reproduire des dizaines de fois.

J'ai failli moi-même me retrouver dans la même situation sur un gros déploiement de système. Les parties prenantes partaient dans tous les sens. Les développeurs devinaient. Nous nous sommes arrêtés, nous avons monté un modèle d'exigences correct et nous avons livré ce dont le métier avait besoin, dans les délais et dans le budget.

L'entreprise d'un ami a dépensé 350 k$ pour un CRM sur mesure que personne n'utilise. Les ventes avaient besoin d'une chose, le marketing en voulait une autre, et les développeurs ont construit ce qu'ils pensaient que tout le monde voulait.

Un de mes clients du secteur de la santé a perdu 18 mois sur la mise en œuvre d'un EMR (dossier médical électronique) que les médecins refusaient d'utiliser. Personne ne leur avait demandé ce dont ils avaient besoin dans leur flux de travail quotidien. Le projet a été abandonné puis relancé.

Découvrir tard coûte cher. Une étude de la NASA sur l'escalade du coût des erreurs a montré qu'une erreur d'exigence détectée pendant l'intégration et les tests coûtait de 21 à 78 fois plus cher à corriger qu'une erreur détectée pendant la phase d'exigences. Détectée en exploitation, le multiple allait de 29 à plus de 1 500. Sur un programme d'entreprise, c'est la différence entre un atelier et une demande de changement à plusieurs centaines de milliers.

1. ExigencesLe coût de référence de la correctionDétectée pendant la rédaction des exigences
2. Intégration et tests21 à 78 fois le coûtDétectée une fois le système construit et en phase de test
3. Exploitation29 à plus de 1,500 fois le coûtDétectée une fois le système en production

Source: étude de la NASA sur l'escalade du coût des erreurs

Après l'avoir appris à mes dépens, voici les cinq sections qu'aucun modèle d'exigences ne devrait omettre.

1. Une synthèse de direction avec un bloc de signatures

Des dirigeants débordés ne liront pas un document d'exigences de 30 pages. J'ai eu un jour un sponsor qui a approuvé un projet sans comprendre ce qu'il signait, avant de s'emporter en découvrant le résultat. Tenez-vous-en à une page : impact métier, calendrier, ressources, bénéfice attendu et un bloc de signatures sur cette même page, pour que les signataires ne puissent pas prétendre avoir manqué les détails critiques.

2. Cartographie des rôles et de l'influence

Une liste de noms ne suffit pas. Il vous faut une carte des pouvoirs : qui peut faire couler le projet, qui doit être consulté, qui a seulement besoin d'être informé. Dans un poste précédent, nous en étions à six mois de développement quand le service juridique est arrivé avec des exigences qui ont imposé une refonte. Personne n'avait pensé à les intégrer. Cartographiez chaque service concerné, son représentant et son influence.

3. Des objectifs métier, pas des exigences techniques

Quel problème résolvons-nous, et comment mesurerons-nous le succès ? Un client du secteur industriel a mis en place un logiciel de gestion des stocks exactement comme spécifié, et il a ralenti de 20 % les opérations d'entrepôt. Le modèle doit obliger les parties prenantes à définir le succès métier à partir d'une situation de référence actuelle, et non d'une liste de fonctionnalités.

4. Des exigences fonctionnelles que les développeurs peuvent utiliser

Laissez le jargon de côté. Rendez chaque exigence précise et testable. « Le système doit améliorer l'expérience client » ne sert à rien. « Les utilisateurs doivent pouvoir traiter un retour et émettre un remboursement en moins de 3 minutes » est une exigence. Si vous ne pouvez pas vérifier qu'elle a été remplie, réécrivez-la.

5. Les exigences non fonctionnelles

Performance, sécurité, conformité, disponibilité, évolutivité. C'est la section que presque tout le monde saute, et le système s'effondre ensuite sous la charge ou échoue à un audit de sécurité. J'ai entendu parler d'un projet dans la distribution où le système fonctionnait parfaitement jusqu'au Black Friday, où il s'est effondré sous la charge parce que personne n'avait spécifié d'exigences de performance. Notez sous forme de chiffres les temps de réponse, les taux de disponibilité, les pics de charge utilisateurs et les obligations de conformité.

Voici le plan complet. Les cinq sections ci-dessus s'y trouvent, aux côtés des registres qui le maintiennent vivant après la validation finale.

Section	Contenu	Responsable	Validé par
1. Synthèse de direction	Problème, impact métier, calendrier, ressources, bénéfice attendu. Une page avec bloc de signatures	Sponsor, rédigée par le responsable analyse métier	Sponsor et finance
2. Périmètre et socle de déploiement	Dans et hors périmètre, contraintes. Pour SAP : Public Edition, Private Edition ou on-premise	Directeur de programme	Comité de pilotage
3. Carte des rôles et de l'influence	Services, représentants, niveau d'influence, à consulter ou à informer	Responsable analyse métier	Sponsor
4. Objectifs métier	Chaque objectif avec un KPI, sa valeur de référence actuelle et une cible	Propriétaires de processus	Sponsor
5. Exigences fonctionnelles	ID (p. ex. REQ-FUN-023), description, origine, priorité, critères d'acceptation, décision fit-to-standard	Responsables fonctionnels	Propriétaires de processus
6. Exigences non fonctionnelles	Performance, sécurité, conformité, disponibilité ; pour SAP, l'approche d'extension retenue pour chaque écart	Architecte de solution	Informatique, sécurité et conformité
7. Parking lot	Demandes reportées, demandeur, date de la prochaine revue	Responsable analyse métier	Aucun jusqu'à promotion
8. Registre des rejets	Ce qui a été rejeté, pourquoi, quand et par qui	Responsable analyse métier	Sponsor
9. Registre des changements	Chaque changement après validation, avec son impact sur les délais et les coûts	PMO	Comité des changements

1. Utilisez les cinq pourquoi dans les entretiens avec les parties prenantes

Demandez « de quoi avez-vous besoin ? » et vous obtenez une liste de souhaits. Interrogez plutôt sur la douleur : « Qu'est-ce qui vous donne envie de jeter votre ordinateur par la fenêtre ? » Demandez ensuite pourquoi, puis encore pourquoi, cinq fois de suite. L'exigence réelle est généralement différente de la première demande.

J'ai eu une partie prenante qui insistait pour avoir des fonctions de reporting complexes. Une fois ses cas d'usage réels passés en revue, il lui fallait trois tableaux de bord simples.

2. Créez un parking lot des exigences

Une bonne part de ce que demandent les parties prenantes ne sera jamais utilisée. Quand quelqu'un insiste sur une demande discutable, je ne discute pas. Je la mets dans le parking lot et j'envoie chaque mois un rappel pour demander si elle doit passer dans les exigences actives. La plupart y restent définitivement.

3. Appliquez la règle des trois aux parties prenantes qui changent sans cesse d'avis

Elles peuvent changer de direction deux fois sans conséquence. Au troisième changement, elles écrivent à leur supérieur pour expliquer le changement et son impact. Personne n'a envie d'envoyer ce mail. Les changements s'arrêtent.

4. Utilisez la technique de répartition budgétaire pour forcer la priorisation

Donnez à chaque partie prenante 100 dollars virtuels à répartir sur l'ensemble des exigences. Elle ne peut pas tout avoir, alors elle met l'argent là où ça compte. Je l'ai fait avec un client des services financiers qui avait plus de 200 exigences « critiques ». En une heure, nous avions le vrai top 20.

5. Numérotez chaque exigence

Adoptez un format cohérent, par exemple REQ-FUN-023. Il met fin à la confusion du « de quelle exigence parle-t-on ? » qui fait perdre du temps en réunion. Consignez l'origine, qui a demandé et pourquoi, pour savoir qui appeler quand il faut couper des éléments.

6. Restituez les exigences dans le langage de la partie prenante

Une fois les exigences documentées, relisez-les aux parties prenantes avec leurs propres mots. Construisez un prototype rapide ou une maquette fil de fer pour tout ce qui est complexe avant le début du développement. Les malentendus apparaissent tant qu'ils coûtent encore peu.

7. Documentez ce qui a été rejeté

Quelqu'un ressortira une exigence rejetée au cinquième mois. « Nous en avons discuté en avril, et voici pourquoi nous avons décidé de ne pas la retenir » met rapidement fin à cette conversation. Sans le registre, vous rouvrez la même dispute.

Ces sept astuces valent pour n'importe quel projet. Les programmes SAP ont besoin de trois éléments supplémentaires dans le modèle.

Le modèle de déploiement entre dans le socle de référence

Fixez le modèle de déploiement avant de recueillir les exigences fonctionnelles : S/4HANA Cloud Public Edition (via GROW with SAP, ou RISE), Private Edition (généralement via RISE) ou on-premise. Il détermine ce qui est possible. La Public Edition n'autorise aucune modification du noyau, de sorte que les exigences qui reposent sur des processus non standard doivent être remodelées ou rejetées. La Private Edition et l'on-premise en permettent davantage, au prix d'un effort de mise à niveau.

Si vous recueillez les exigences avant cette décision, vous en réécrirez beaucoup au moment où elle tombera.

Une décision d'extension pour chaque écart

L'approche clean core de SAP impose de consigner une décision pour chaque écart : le configurer, l'étendre au moyen d'API publiées (on-stack avec ABAP Cloud ou side-by-side sur SAP BTP), ou le rejeter. Sur la Public Edition, c'est le produit qui l'impose. Sur la Private Edition et en on-premise, c'est une recommandation forte de SAP, et chaque modification que vous autorisez devient du travail de mise à niveau plus tard. Placez la décision dans la section 6 du modèle, à côté de la performance et de la sécurité, et donnez à un seul architecte le pouvoir de l'approuver. Mon guide du clean core en explique les niveaux.

L'IA rédige, les humains décident

L'IA aide désormais pour la paperasse. SAP Cloud ALM propose une fonction de génération d'exigences qui rédige des exigences dans un modèle à partir des transcriptions d'ateliers fit-to-standard, facturée en unités d'IA. Des assistants généralistes comme Microsoft Copilot rédigent des synthèses et des comptes rendus à partir de notes de réunion.

Les outils de rédaction par IA font gagner un temps réel sur la paperasse quand la matière de départ est propre. Ils ne changent rien à l'entretien. C'est toujours un humain qui pose les cinq pourquoi. Et aucun outil ne fera signer la synthèse de direction à un chef de service. La validation, la priorisation et la signature restent un travail humain.

Développement logiciel. Ajoutez les contraintes techniques, les points d'intégration, les parcours utilisateur (les étapes réellement suivies par les utilisateurs, pas seulement les fonctionnalités) et des critères d'acceptation de type réussite ou échec. Nous l'avions oublié sur un projet de portail client et nous avons passé trois mois à débattre pour savoir si les fonctionnalités « marchaient correctement ».

Amélioration de processus. Cartographiez l'état actuel avec tous les contournements improvisés dont les gens ne parlent pas en réunion, évaluez l'impact par rôle et relevez des valeurs de référence de performance chiffrées. Un client du secteur industriel a refondu son processus d'entrepôt sans valeurs de référence. Six mois plus tard, il ne pouvait ni prouver l'amélioration ni justifier la dépense.

Sélection de fournisseur. Séparez l'indispensable du souhaitable, pondérez les critères de notation et détaillez les attentes en matière de support et de mise en œuvre jusqu'à en être pénible. J'ai vu une entreprise choisir un fournisseur presque uniquement sur les fonctionnalités et l'impression laissée par les démonstrations. Elle a ignoré les exigences de support et s'est retrouvée avec un système qu'elle ne pouvait pas mettre en œuvre sans de lourds frais de conseil supplémentaires.

Pour les petits projets : Trello pour faire passer les exigences d'une étape d'approbation à l'autre, Google Docs avec commentaires pour la relecture et Miro pour la cartographie des processus en atelier.

Pour les programmes d'entreprise : Jira avec un module complémentaire de gestion des exigences, Confluence pour les documents vivants (ses fonctions d'IA relèvent désormais de la marque Rovo d'Atlassian), et Modern Requirements si vous travaillez sous Azure DevOps. Sur les programmes SAP, SAP Cloud ALM réunit exigences, user stories et cas de test au même endroit, reliés à la feuille de route SAP Activate.

L'outil compte moins que le lien. Reliez les exigences à votre plan de projet et à vos cas de test, et envoyez des notifications automatiques quand une exigence change. « Je ne savais pas que ça avait changé » tue plus de projets qu'un outillage médiocre. Une fois les exigences validées, mon guide pour éviter la dérive du périmètre dans les projets SAP explique comment les maintenir ainsi, et les quality gates SAP montrent où la validation des exigences s'insère dans le cycle de gouvernance.

Un modèle que personne n'ouvre après la validation, c'est du théâtre. Ceux qui fonctionnent sont courts, pris en charge section par section et mis à jour chaque fois que quelqu'un change d'avis, ce qui, sur tout programme qui mérite d'être mené, arrive chaque semaine.

Quelles sont les 5 étapes de la collecte des exigences ?

1. Élicitation : recueil d'informations par des entretiens, des ateliers et de l'observation
2. Analyse : organisation, priorisation et résolution des conflits entre exigences
3. Documentation : rédaction de la spécification (BRD, FRD ou user stories, selon la méthode)
4. Validation : vérification que les exigences reflètent des besoins réels et qu'elles sont testables
5. Gestion : suivi des changements pendant le reste du projet

Chaque étape s'appuie sur la précédente. Bâcler l'élicitation, ce que font la plupart des équipes, crée des problèmes à chaque étape suivante.

Quelle est la différence entre un BRD et un FRD ?

Un document d'exigences métier (Business Requirements Document, BRD) couvre les besoins du métier : contexte, objectifs, parties prenantes, contraintes et exigences de haut niveau. Il répond à la question « de quoi le métier a-t-il besoin ? »

Un document d'exigences fonctionnelles (Functional Requirements Document, FRD) décrit le comportement du système : user stories, comportement du système, interfaces et critères d'acceptation. Il répond à la question « que doit faire le système ? »

Je commence toujours par le BRD pour obtenir l'alignement du métier avant le FRD. Les équipes qui sautent directement au FRD construisent souvent un système techniquement correct qui résout le mauvais problème.

Quels sont les 3 types d'exigences ?

1. Exigences métier : pourquoi le projet existe, ses objectifs et ses mesures de succès
2. Exigences fonctionnelles : ce que le système doit faire
3. Exigences non fonctionnelles : avec quel niveau de qualité il doit le faire (performance, sécurité, évolutivité, conformité)

La plupart des échecs de projet que j'ai vus remontent à des exigences non fonctionnelles manquantes. Le système fait ce qui a été demandé, puis s'effondre sous une charge réelle ou échoue à un audit de conformité.

En quoi le modèle de déploiement SAP change-t-il la collecte des exigences ?

Fixez-le en premier. S/4HANA Cloud Public Edition n'autorise aucune modification du noyau, donc les exigences fondées sur des processus non standard doivent être remodelées ou rejetées. La Private Edition et l'on-premise offrent plus de souplesse, mais chaque modification ajoute de l'effort de mise à niveau.

Si vous recueillez les exigences fonctionnelles avant la décision, vous en retravaillerez beaucoup. Ajoutez une décision d'extension consignée (configurer, étendre par des API publiées, ou rejeter) pour chaque écart.

Qu'est-ce qui rend une exigence testable ?

Une condition de réussite ou d'échec claire et mesurable. « Le système doit être rapide » n'est pas testable. « Les résultats de recherche doivent s'afficher en moins de 2 secondes pour 95 % des requêtes en charge standard » l'est.

Mon test : pouvez-vous écrire le cas de test tout de suite, avec des critères de réussite et d'échec clairs ? Sinon, réécrivez l'exigence. Les exigences non testables provoquent plus de litiges au go-live que tout le reste de ce que je vois.

Comment éviter que les exigences changent en permanence ?

1. Contrôle des changements : tout changement après la validation documente son impact sur les délais, le budget et les ressources avant que quiconque l'approuve. Rendez visible le coût du changement.
2. Parking lot : les nouvelles demandes vont dans le parking lot, pas directement dans le périmètre. Passez-les en revue chaque mois. La plupart des demandes qui paraissent urgentes ne survivent pas à l'attente.
3. Quality gates : définissez ce que signifie « exigences complètes » et ne démarrez pas la conception tant que ce critère n'est pas atteint.

Sur les programmes SAP, la décision d'extension ajoute un contrôle technique : une demande qui nécessite une modification du noyau doit d'abord passer par l'architecte avant de pouvoir être approuvée.