« La gestion des exigences est une démarche fondamentalement transversale, au croisement du métier, de l’architecture, du projet et de la qualité. » – Stéphane Renaud, Consultant et Formateur en Architecture d’Entreprise

Dans un contexte où les projets de transformation s’accélèrent et se complexifient, la capacité à comprendre, formaliser et piloter les exigences devient un enjeu clé de réussite. Trop souvent encore, des solutions sont développées sans répondre pleinement aux besoins réels des utilisateurs ou des métiers, faute d’un travail suffisant sur leur expression et leur clarification.

Pour éclairer ces enjeux, nous avons rencontré Stéphane Renaud, architecte d’entreprise et référent de la formation « Formaliser et gérer les exigences avec Volere® » . Fort de plusieurs décennies d’expérience, il partage sa vision de la gestion des exigences, les difficultés rencontrées dans les organisations, ainsi que les apports concrets de la méthode Volere® pour structurer cette démarche essentielle.

Dans cet échange, il revient sur son parcours, explique pourquoi la maîtrise des exigences est aujourd’hui plus critique que jamais, notamment à l’ère de l’IA et détaille les objectifs et bénéfices de cette formation pour les professionnels impliqués dans les projets IT, produits et de transformation.

Je viens d’un parcours assez classique d’architecte d’entreprise. Dans ce cadre, on s’appuie notamment sur TOGAF, le framework d’architecture de l’Open Group qui amène à se poser les bonnes questions avant de chercher des solutions.

Cette démarche pousse à se demander : Me suis-je bien intéressé à toutes les personnes concernées par le projet ? Ai-je bien compris leur métier, leurs besoins, la façon dont la solution s’intégrera dans leur futur contexte de travail ?
L’élément central de cette démarche d’architecture est la gestion des exigences : s’assurer que l’on fait vraiment tout ce qu’il faut pour les clarifier, les formaliser, les prioriser et les suivre.

Avant cela, quelque soit mes rôles, comprendre les métiers, partager une compréhension commune des besoins entre ceux qui les expriment et ceux qui vont les réaliser a toujours été au cœur de ma pratique.
La méthode propose précisément une approche structurée de management des exigences pour garantir que la solution mise en œuvre réponde réellement aux besoins exprimés. Elle cadre la pensée, les questionnements, la façon de poser les bonnes questions et de ne rien oublier. On peut la voir comme une forme de checklist qui permet de s’assurer que les besoins sont exprimés correctement, complètement et de manière cohérente.

Pour moi, la gestion des exigences est une démarche fondamentalement transversale, au croisement du métier, de l’architecture, du projet et de la qualité.

Aujourd’hui, pourquoi la question des exigences est-elle devenue aussi centrale dans les projets (IT, produits, transformation…) ?

Elle est centrale parce qu’un grand nombre de projets ne répondent pas, au final, aux besoins réels des utilisateurs ou du métier. En voulant aller trop vite on en oublie les fondamentaux et on se rend compte qu’en chemin, les besoins ont été mal compris, interprétés, simplifiés à l’excès, ou qu’on a cru savoir ce qui était mieux pour le client sans vérifier avec lui.

La bonne gestion des exigences permet de mieux comprendre ces besoins et de mieux les partager. Elle remet la responsabilité au bon endroit, du côté des métiers, des business analysts, des product owners…

On les accompagne pour qu’ils expriment clairement ce dont ils ont besoin, pourquoi ils en ont besoin, et dans quel contexte. Si l’on pose les bonnes questions dès le départ, on augmente considérablement les chances de trouver une solution pertinente.

Mais avant de parler solution, il faut faire le tour de l’environnement de besoins : acteurs, usages, contraintes, contexte, futur souhaité. C’est cette exploration qui donne de la solidité à la décision et à la solution retenue.

Concrètement, quels types de problèmes rencontres‑tu souvent dans les organisations quand les exigences sont mal formalisées ou mal gérées ?

Quand les exigences sont mal formalisées, on ne sait pas vraiment ce qu’il y a dans la tête de la personne qui a émis l’idée. On ne connaît pas non plus la légitimité de cette personne à porter ce besoin : a‑t‑elle l’autorité ou la vision nécessaire, mesure-t-elle les impacts et les coûts associés ?

On n’est pas certain qu’elle ait compris l’audience à laquelle l’exigence s’adresse ni la manière dont on vérifiera par la suite que « ça marche ». Sans clarification, on ouvre la porte à la sous‑qualité (on ne fait pas assez) ou à la sur‑qualité (on en fait trop, ou à côté). Aujourd’hui, les organisations doivent composer avec un grand nombre d’exigences et de contraintes, et cela nécessite de les rationaliser et de les argumenter.

Sur la partie gestion, le défi consiste à savoir par où commencer, comment lister les exigences, les faire comprendre à tous, du développeur au testeur,  puis les prioriser.

Il faut vérifier que tout ce qui est demandé va dans la même direction, sans contradiction entre les services et les départements consultés. Quand une exigence n’est pas comprise ou semble incohérente, il est important de la renvoyer à son « éditeur », de la challenger pour pouvoir mieux la traiter ensuite, selon les critères de qualité et de cohérence souhaités.

En quoi la maîtrise des exigences devient-elle encore plus critique à mesure que l’IA accélère le développement des solutions ?

L’IA accélère la production, mais elle amplifie aussi les incompréhensions. Le véritable enjeu n’est donc plus seulement de produire plus vite, mais d’éviter de produire très vite une solution inadéquate. Sans une gestion précise, structurée et validée des exigences, avec  l’IA on peut développer plus vite, mais pas forcément juste. En clair, l’IA ne compense pas une faible maîtrise des exigences, elle la sanctionne plus vite, plus fort et à plus grande échelle.

Pour quelqu’un qui ne la connaît pas, comment définirais‑tu la méthode Volere® en quelques phrases ?

Volere® part d’un principe simple : tout est une question de communication. Notre responsabilité est de tout faire pour bien se comprendre, et cela commence par vérifier qu’un besoin a été exprimé de façon claire.

La démarche Volere® consiste à se demander, pour chaque exigence, si elle est claire, non ambiguë, compréhensible par tous, testable et priorisée. Elle invite également à vérifier que l’on n’oublie aucun acteur important : à la fois les parties prenantes directement impliquées et même les « negative stakeholders », ceux qui peuvent nuire à la solution.

Enfin, Volere® amène à préciser le périmètre à couvrir et le but à atteindre. C’est cette articulation entre but, périmètre et parties prenantes qui donne un cadre solide à la suite du projet.

En quoi Volere® se distingue‑t-elle des autres approches de recueil et de formalisation des exigences disponibles sur le marché ?

Beaucoup d’approches insistent sur les différentes méthodes de recueil des besoins. Bien sûr c’est important pour démarrer, mais insuffisant pour garantir la complétude, la cohérence, l’adéquation et la testabilité des exigences.

Les autres approches sont souvent trop simplistes et ne vont pas assez loin dans le fait de challenger l’exigence : qui l’a formulée, pourquoi, dans quel contexte, comment on la vérifiera, quels sont ses impacts. Volere® se distingue par une vision plus structurée, plus systématique et plus exigeante de la gestion des exigences.

Quels sont les objectifs principaux de la formation « Formaliser et gérer les exigences avec Volere® » proposée par OCTO Academy ?

L’objectif principal est d’apprendre à exprimer un besoin de manière claire, univoque et sans ambiguïté.
Les participants doivent être capables, à l’issue de la formation, de décrire des exigences de façon suffisamment précise pour qu’elles soient comprises de la même manière par tous.

Nous cherchons également à faire en sorte d’intégrer toutes les dimensions pertinentes : métiers, techniques, organisationnelles, exigences fonctionnelles et non fonctionnelles.
Un point clé est de ne pas démarrer un projet tant que le triptyque périmètre / but / parties prenantes n’est pas clarifié et validé.

Les participants apprennent aussi à se poser les bonnes questions contextuelles pour identifier et gérer les exigences non fonctionnelles (performance, sécurité, contraintes d’usage, etc.), afin de ne pas oublier les personnes qui utiliseront effectivement la solution.
En résumé, la formation aide à aligner ceux qui décident, ceux qui construisent et ceux qui vont vivre avec la solution.

Quelles compétences et savoir‑faire les participants peuvent‑ils espérer avoir acquis à l’issue de la formation ?

À l’issue de la formation, les participants sont capables :

de définir le contexte du projet, le but poursuivi et la liste des parties prenantes à interroger ;
de cadrer le périmètre de manière à ne rien oublier, sans pour autant aller au‑delà de ce qui est réellement attendu ; de comprendre les besoins exprimés par différentes équipes au sein d’une même organisation et de les challenger; de décrire une exigence de manière non ambiguë, claire et testable ; de mettre en place une étape d’arbitrage où les exigences sont comprises, discutées et priorisées collectivement.

Ils ressortent avec une démarche structurée et des réflexes concrets pour mieux piloter les exigences au quotidien.

Comment se déroulent concrètement ces deux jours : équilibre entre apports théoriques, exercices pratiques et études de cas ?

La formation se déroule sur deux jours.
Elle alterne en permanence apports théoriques, retours d’expérience et mises en situation.

Nous commençons typiquement par un chapitre de théorie, puis nous partageons des retours d’expérience pour illustrer la mise en œuvre de la démarche d’architecture et de Volere® sur de vrais projets.
Immédiatement après, les participants travaillent sur des exercices pratiques pour ancrer les concepts.

Sur les deux jours, nous avons prévu une douzaine de cas pratiques.
L’idée est que les apprenants passent un maximum de temps « en situation », à appliquer l’approche Volere® plutôt qu’à seulement l’écouter.
Ils repartent ainsi avec une véritable boîte à outils et une manière opérationnelle de gérer les fiches d’exigences.

Quels types de supports ou d’outils les participants repartent-ils avec ? (modèles de documents, check‑lists, canevas Volere, etc.)

Les participants repartent avec plusieurs templates, dont un modèle de fiche pour décrire une exigence de manière unitaire (la « snow card »).

Ce format les oblige à être synthétiques et précis, et à se poser les bonnes questions pour chaque exigence.

Ils disposent également d’une vingtaine de thèmes de questions à utiliser pour qualifier les exigences non fonctionnelles, les performances, la sûreté, les approches techniques, etc.

Ces questions permettent de vérifier s’il y a un enjeu spécifique sur chaque dimension et de voir comment la solution envisagée couvre réellement les besoins

Si tu devais donner un premier conseil à quelqu’un qui veut mieux gérer les exigences dès demain, sans tout révolutionner, ce serait lequel ?

Je commencerais par les parties prenantes.
La question à se poser est : est-ce que toutes les personnes concernées de près ou de loin par la transformation sont bien identifiées, consultées et priorisées ?

Si l’on manque des parties prenantes, on passe à côté de pans entiers de questionnements et de besoins.
Une fois cet inventaire réalisé, il faut prioriser les parties prenantes pour savoir quels acteurs clés rencontrer en premier, sur quels sujets, et ce qui est le plus nécessaire immédiatement.
Ensuite, on peut valider le périmètre et le but du projet, avec une vision beaucoup plus solide.

Quel est, selon toi, le bon état d’esprit à adopter pour tirer le maximum de la méthode Volere® et de la formation ?

Il faut adopter un état d’esprit d’écoute active et de participation active.
C’est une formation très dynamique, exigeante, avec beaucoup d’exercices qui s’enchaînent.

Plus les participants s’impliquent, posent des questions, testent la méthode sur leurs propres contextes, plus ils en retirent de la valeur.
Volere® n’est pas seulement une grille ou un gabarit, c’est une discipline de dialogue entre les métiers, les équipes techniques et les parties prenantes.

Pour finir, peux‑tu partager un repère marquant de ton parcours qui éclaire ton intérêt pour les exigences métier ?

J’ai commencé l’informatique en 1979. Ce qui a toujours été le plus important pour moi, tout au long de ma carrière, c’est la compréhension des besoins des métiers : être certain de saisir ce qui est vraiment en jeu pour eux dans les solutions que l’on met en place.

Quel que soit le domaine, la compréhension commune des besoins est à mes yeux, la chose la plus importante. C’est finalement le moyen le plus concret de respecter cette priorité afin de trouver la solution en adéquation avec les exigences.