Enquête « Quelles pratiques pour des spécifications fonctionnelles “parfaites” » ?

Les pratiques de création et de transcription des spécifications fonctionnelles

Quelle méthodologie pour les projets de création d’application ?

Grâce à notre étude, nous constatons que les méthodes agiles sont privilégiées lors d’un projet de création et de développement d’application. Ces méthodes représentent plus de la moitié des cas d’utilisation. Pourtant, le choix de la méthodologie est à remettre en perspective. Pour beaucoup de personnes interrogées, il dépend de « la taille du projet », « des projets et des différents intervenants », « du projet et des besoins », « du client et de sa maturité », ou encore « des interlocuteurs, des attendus ». Les méthodes s’adaptent donc selon plusieurs facteurs. « Certains projets n’utilisent pas non plus de méthode “officielle” mais globalement, cela ressemble à de l’agile », nous confie même un répondant.

Si les méthodes varient selon les projets, les besoins, la maturité et le niveau de technicité des interlocuteurs, nous pouvons imaginer que ces facteurs impactent la manière dont sont réalisées les spécifications.

De plus, quelle que soit la méthodologie choisie, la documentation des spécifications nécessite une mise à jour. En effet, les méthodes agiles fonctionnent par sprints et les méthodes classiques fonctionnent fréquemment par lotissement. Des spécifications mises à jour permettent une documentation à jour. Il est donc primordial de bien faire ses spécifications, et également de bien les documenter. Ce sont deux étapes différentes mais complémentaires. 

Projets low code no code : échapperaient-ils à la réalisation des spécifications ?

Outre l’approche méthodologique, la manière dont est réalisé le projet détermine le niveau de détail des spécifications fonctionnelles. Un répondant nous interpelle : « Si le projet est réalisable avec du low code pourquoi le spécifier ? Une documentation suffit ». Cet avis divise, car d’autres personnes pensent que les spécifications sont indispensables : « Les SFG (spécifications fonctionnelles générales) sont importantes dans les cas des projets high code ainsi que low code ». Toutefois, environ 47% des répondants ne réalisent jamais les spécifications pour des projets d’application en low code no code, et environ 35% ne le font que rarement.

Dans le cas de projet en low code no code, nous constatons donc que les spécifications fonctionnelles sont très peu faites. Pour autant, dans de nombreux autres projets hors de ce champ d’action low code no code, les spécifications fonctionnelles ne sont pas toujours bien détaillées… Nous verrons que les outils utilisés ont aussi un rôle à jouer dans la rédaction des spécifications !

Avec quels outils sont rédigées les spécifications fonctionnelles ?

Les outils bureautiques sont très majoritairement adoptés pour réaliser les spécifications fonctionnelles. En effet, près de 75% des répondants indiquent utiliser des outils bureautiques pour réaliser des spécifications fonctionnelles : traitement de texte, tableur, outils de présentation. 21% utilisent Confluence et/ou Jira (dans un contexte d’agilité) alors que seulement 4% utilisent d’autres outils spécifiques (comme la solution de modélisation Enterprise Architect). Les outils bureautiques sont les plus utilisés pour rédiger les spécifications. Il est par conséquent légitime de se demander s’ils sont bien adaptés. 

Quels problèmes posent ces outils majoritairement utilisés ?

Nul besoin de revenir sur les avantages des outils bureautiques, connus et reconnus du public professionnel, facilement accessibles et maîtrisables. Pour autant, ces outils sont-ils adaptés et en adéquation avec les attentes des utilisateurs ?

Pour les répondants de l’enquête,  les outils bureautiques posent des problèmes liés à la réalisation des spécifications. Ces outils ne permettent pas de créer des visuels « assez clairs », « optimaux ». S’ils rencontrent « majoritairement des problèmes de mise en forme », ce ne sont pas les seules difficultés auxquelles ils font face. 

Certains déplorent le manque de « traçabilité et maintenabilité », « d’ajout des commentaires de la part du client validateur », la « maintenance et les dépendances (qui sont) compliquées à gérer », ou encore le manque de cohérence dans le travail d’équipe.

Pour ces professionnels, les outils ne permettent pas, lors de la rédaction des spécifications, d’avoir une vision, un historique et un suivi précis. La documentation semble difficile à construire a posteriori. Par exemple, à la question « Quels problèmes vous posent les outils que vous utilisez pour la rédaction des spécifications fonctionnelles ? », les sondés nous répondent : « La centralisation pour une meilleure recherche des spécifications en postproduction »; « L’historisation des spécifications pour comprendre comment l’actuelle spécification a été construite »; « Pour Word ou Excel, c’est l’éparpillement des fichiers et en général pas de possibilité de réaliser directement des maquettes »; « Pas de mise à jour automatique de date ou numéro de version »… De nombreux problèmes liés à l’utilisation de ces outils bureautiques sont mis en avant.

Nous constatons donc que les spécifications ne sont pas toujours suffisamment détaillées, que ce soit à cause de la taille du projet, des outils utilisés, ou du type de projets réalisés. Cela impacte aussi la création de la documentation fonctionnelle. Il est important de comprendre la nuance entre la réalisation des spécifications et la réalisation de la documentation ; les spécifications servent à faire, et la documentation à comprendre. Mais alors, quelles seraient les conséquences d’une négligence de ces deux éléments ? 

Les problèmes liés au défaut de documentation fonctionnelle

Est-ce vraiment contraignant de ne pas avoir une documentation fonctionnelle à jour ?

Une documentation fonctionnelle qui n’est pas à jour est problématique pour plus des 3/4 des répondants. Elle est même considérée comme « très problématique » pour 1/3 d’entre eux. 

Presque tous s’accordent sur ce sujet ; seulement 3% considèrent que le manque de documentation fonctionnelle à jour n’est pas problématique. Il y a donc une vraie perception de l’intérêt à en disposer pour le bon développement et la  pérennisation d’une application.

La documentation fonctionnelle : une difficulté réelle de mise à jour ?

La documentation fonctionnelle est « toujours » mise à jour par moins d’un tiers des répondants. En contrepartie, elle est « souvent » mise à jour par 37% d’entre eux, et « rarement » pour 25% d’entre eux. Aussi, 5% ne mettent « jamais » la documentation à jour.

« On essaie, mais des loupés arrivent », « On essaie autant que faire se peut, mais il arrive qu’il y ait des oublis », nous expliquent les répondants. C’est « extrêmement chronophage », justifie un autre. 

Cette tendance globale s’explique par l’effort important que demande la modification des spécifications avec des outils bureautiques ou de gestion de projet inappropriés.

Cette même question, posée à des développeurs en 2021, apporte des réponses plus marquées encore : 10,3% d’entre eux, seulement, indiquent « toujours » mettre à jour les spécifications fonctionnelles de façon à disposer d’une documentation à jour.

Comment expliquer le manque de mise à jour ?

Lorsque les spécifications fonctionnelles ne sont pas mises à jour au fur et à mesure des changements, la principale raison évoquée est le manque de temps ou de budget (environ 70% des réponses).

Par comparaison, en 2021, la même raison était donnée par les développeurs (à hauteur de 55% des réponses).

La seconde raison (21% des répondants) est que « ce n’est pas vraiment nécessaire », principalement lorsque les méthodes agiles sont utilisées. En effet, chaque évolution fait l’objet d’une nouvelle user story qui peut en recouvrir une ou plusieurs autres. À cela s’ajoute le fait que les outils utilisés en agilité, comme Jira, ne fournissent pas de documentation sur l’ensemble de l’application. 

Notons aussi que les 2/3 des business analysts qui jugent que « ce n’est pas vraiment nécessaire » indiquent toutefois que des spécifications qui ne sont pas à jour sont problématiques. 

Ce paradoxe s’explique en partie par la réalité du terrain et des équipes. Lors de la rédaction d’une spécification, une partie concerne la description de la fonctionnalité ou user story en elle-même  (ce qui doit être fait), et une autre partie concerne le contexte, c’est-à-dire les fonctionnalités existantes qui devront être prises en considération. En général, le contexte est connu des développeurs ; il se transmet par l’expérience ou l’immersion. Le problème survient lorsque ce contexte est implicite, facilitant les oublis. Aussi, d’autres facteurs humains (changement d’équipe, départ de salariés, instabilité de l’équipe, niveau de communication…) peuvent favoriser ces oublis, qui plus tard, seront problématiques.

Quelles en sont les conséquences ?

Le principal problème que pose le manque de documentation à jour porte sur la bonne compréhension de l’application (problème évoqué dans 29% des réponses).

À défaut d’une documentation claire sur laquelle baser les échanges, ce manque de mise à jour se traduit par des problèmes de collaboration avec les utilisateurs (8%). La transmission du savoir est problématique (15% des réponses). Il est plus difficile pour les nouveaux collaborateurs de « rentrer sur le projet ». Ils risquent ainsi de passer à côté d’informations importantes. « Cela peut être problématique si la personne qui l’a écrite est partie. Dans ce cas on part à la “chasse aux infos”», témoigne un répondant. Ce problème est accru lorsqu’une nouvelle équipe reprend le projet.  « Des spécifications obsolètes, c’est la cata ».

Les participants évoquent diverses difficultés. « Le problème se pose notamment pour les tests », car il existe des doutes. Il faut donc tester l’application pour connaître ses fonctionnalités, voire examiner le code source. « Pas facile de reprendre des spécifications pas à jour, par exemple pour savoir ce qu’il faut tester. La tenue à jour est aisée… Le rattrapage infernal ! » nous confie un spécialiste.

La difficulté corollaire porte également sur la réalisation des tests (11% des réponses). En effet, comment tester la réponse de l’application face aux besoins (ou à défaut) des spécifications à jour ? La validation métier ne sera pas pertinente. Cela pose en autre un problème de qualité.

Il est également difficile de trouver les règles métier ou de connaître le fonctionnement de l’application sur des points précis qui sont souvent impactants. Le risque est de prévoir des changements qui, d’une façon ou d’une autre, ont déjà été implémentés, mais n’ont pas été documentés. Il est aussi difficile de déterminer si un problème vient d’une régression ou d’un besoin non exprimé.

En conséquence, des problèmes de maintenance peuvent intervenir (15% des réponses). Difficile donc de faire la différence entre les anomalies et les évolutions. Au-delà de cette difficulté de qualification, le risque est de réaliser une mauvaise implémentation d’une correction ou d’une évolution dont l’analyse est basée sur des spécifications obsolètes. Les risques de régression sont plus particulièrement mentionnés et mis en avant par 7% des répondants.

Au final, le défaut de documentation fonctionnelle à jour pose des problèmes de productivité : perte de temps en discussions et recherche d’informations, mobilisation inutile de ressources pour des évolutions dont l’analyse est faussée, confusion qui ralentit les travaux, développements compliqués et chronophages. Il est donc naturel de demander quelles pourraient être les attentes et les solutions.

Les défis et attentes majeurs des utilisateurs face aux outils de spécification et de documentation fonctionnelle

Le souhait d’un gain de temps rédactionnel

Plusieurs attentes émergent quant au gain de temps sur la partie rédactionnelle. Parmi ces attentes, la lisibilité et la mise à jour des spécifications (ou users stories) sont les plus citées. En effet, environ 19% des professionnels souhaitent gagner du temps lors de la rédaction des spécifications, et 8% des autres professionnels aimeraient plus de lisibilité, ou plus de simplicité sur les mises à jour de la documentation. Un gain de temps pour la mise en page est aussi désiré. En effet, environ 12% des répondants expriment leur souhait d’une mise en page simplifiée. 

Le souhait d’un gain de temps technique

Les outils utilisés en spécifications fonctionnelles permettent très rarement la génération automatique de code. En effet, seulement 4.4% des répondants affirment disposer d’un outil permettant de réaliser ses spécifications et de pouvoir bénéficier ainsi de code généré automatiquement. 

Sur les 90% des répondants dont les outils de spécifications ne permettent pas de générer automatiquement du code,  40.9% de répondants pensent que cela pourrait être utile, et 46.7% pensent que cela ne le serait pas.

Parmi ces répondants, certains nous disent que « Générer du code c’est bien, mais je remarque que souvent, il faut l’adapter », que « Pour avoir déjà travaillé avec des générateurs de code, je ne suis pas très fan de ce genre d’outil. Ça peut aider par moment, mais ça finit toujours par bloquer et on va devoir faire du code à la main à partir de code généré. Pas toujours évident. Autant faire à la main dès le départ ». D’autres répondants sont plus optimistes et pensent que cela « peut être utile au développeur ».

Le gain de temps pour la rédaction des plans de tests et leur exécution est aussi demandé. Près de 10% des répondants voudraient gagner du temps sur la phase de rédaction et de lancement de tests. 

Toujours dans cette optique de gain de temps, d’autres répondants aimeraient avoir « des maquettes qui se feront au fur et à mesure de la rédaction, sans devoir utiliser un autre outil pour les faire ». Toutes les stratégies pour gagner en temps, et de facto en efficacité et performances, sont retenues.

Existe-t-il une solution / un outil magique pour y répondre ?

Au regard des problèmes soulevés et des attentes détectées, il serait intéressant de voir naître un outil dédié à la réalisation des spécifications fonctionnelles détaillées capable d’améliorer la qualité et la productivité.

Pour améliorer la qualité des spécifications, il faudrait améliorer la complétude et la clarté des spécifications afin d’éviter diverses interprétations qui peuvent conduire à l’inadéquation des besoins, à des pertes de temps et à des problèmes budgétaires. 

Cela peut passer par l’implémentation fonctionnelle des principes de modélisation UML (définition des acteurs, des fonctionnalités, des cas d’utilisation et des scénarios, des exigences fonctionnelles et non fonctionnelles, génération automatique de diagrammes).

Pour améliorer la productivité des spécifications, il faudrait augmenter la rapidité de réalisation des spécifications grâce à une bonne définition des concepts et de leurs relations entre eux. 

Par exemple, il faudrait pouvoir générer automatiquement des cas d’utilisation CRUD (création / lecture / mise à jour / suppression) avec des scénarios standard, et générer automatiquement, par la même occasion, les formulaires, les listes et les tableaux correspondants.

Aussi, à défaut de documentation fonctionnelle à jour, la spécification d’une évolution nécessite de tester l’application, voire d’examiner le code source pour connaître son fonctionnement, ce qui est chronophage et coûteux.  Grâce à un système de recherche dans la documentation fonctionnelle, il serait judicieux de pouvoir identifier en temps réel les impacts potentiels d’un changement et de posséder un système d’alertes qui identifie des défauts potentiels de spécifications (par exemple un attribut de modèle de données qui n’est utilisé dans aucun formulaire, aucune liste, aucun tableau).

Pour assurer la qualité de la documentation fonctionnelle, il serait idéal d’avoir des mises à jour automatiques de la documentation à partir des spécifications validées en production. Ces modifications pourraient entraîner le report automatique d’une modification dans l’ensemble de la documentation, ce qui permettrait d’éviter les oublis ou les incohérences.

Cet outil est en cours de création et s’appelle Managician. C’est un outil magique qui fait rêver plus d’un professionnel ayant à gérer des projets de création et développement d’application. C’est un projet ayant du sens au regard de cette enquête qui démontre les besoins et attentes sur ces sujets. Pour suivre les évolutions de développement de cet outil, pensez à vous inscrire à notre newsletter qui lui est dédiée, ou à nous suivre sur LinkedIn.