Spécifications fonctionnelles détaillées
Une SFD, dans son principe, c'est le moment où on arrête d'agiter des intentions et où on écrit ce que le système doit faire. Le périmètre fonctionnel posé écran par écran, les parcours utilisateurs déroulés étape par étape, les règles de gestion sorties de la tête des opérationnels et mises noir sur blanc, les exigences non fonctionnelles, performance, accessibilité, sécurité, hébergement, traitées au même niveau de précision. Sur le papier, l'exercice paraît simple. Dans les faits, c'est là que la plupart des projets se jouent : ce qui est mal cadré à ce stade se paie ensuite, en redéveloppement, en arbitrages tardifs, en réunions qui auraient dû se tenir avant la première ligne de code.
Le marché traite souvent ce livrable comme une formalité administrative, ou comme une assurance qu'on signe pour se couvrir si le projet dérape. On voit passer des SFD de quatre-vingts pages que personne n'ouvre une fois la signature obtenue, des documents écrits dans une langue que ni la direction métier ni l'équipe de développement ne lisent vraiment, des spécifications qui décrivent le bouton mais oublient la règle qui décide quand le bouton s'affiche. Quand ces documents existent pour exister, ils encombrent autant qu'ils éclairent. Pire, ils donnent l'illusion qu'un sujet est traité parce qu'un paragraphe lui est consacré, alors que la vraie question n'a pas été posée.
Notre ligne, sur ce livrable, tient en une idée simple. Une SFD est un outil de pilotage projet, pas une pièce de dossier. On l'écrit pour que quelqu'un puisse chiffrer, quelqu'un puisse développer, quelqu'un puisse recetter, et que les trois lisent la même chose. Ça veut dire choisir ce qu'on détaille et ce qu'on laisse plus ouvert, écrire dans une langue que les opérationnels comprennent sans glossaire, et accepter que certaines zones restent volontairement en cadre large parce qu'elles seront mieux tranchées au cours du build qu'au cours du cadrage. Une SFD qui prétend tout figer à l'avance se trompe deux fois : elle bloque l'agilité et elle ment sur la maîtrise réelle qu'on a du sujet à l'instant où on l'écrit.
En pratique, on commence par s'asseoir avec vos équipes. Les directions métier qui portent le besoin, les opérationnels qui font tourner le quotidien, la direction projet qui pilote, et les profils techniques quand ils sont déjà identifiés. On remonte au problème réel sous la demande, on cartographie les parcours actuels avant de dessiner les cibles, on liste les règles de gestion qui dorment dans des têtes ou dans de vieux fichiers Excel. Ce travail d'écoute structurée prend du temps, et c'est lui qui rend la suite utile. Un atelier qui se résume à valider des écrans préparés à l'avance produit une SFD jolie et fausse.
Vient ensuite le travail d'écriture, qui n'est pas un travail de mise en forme. Pour chaque parcours, on déroule les étapes, les conditions, les cas alternatifs, les écrans concernés et les règles qui s'appliquent. Pour chaque écran, on précise le contenu, les actions, les états possibles, les permissions, ce qui se passe quand la donnée manque ou quand l'utilisateur n'a pas le droit. Les wireframes accompagnent quand ils éclairent, pas pour faire joli. Les règles de gestion sont écrites en phrases qu'un opérationnel valide à la lecture, pas en pseudo-code qui sépare ceux qui décident de ceux qui codent. À chaque section, on garde en tête la même question : est-ce qu'un développeur ou un prestataire qui découvre le projet peut, en lisant ça, chiffrer et construire sans ambiguïté majeure ?
Les exigences non fonctionnelles, performance, accessibilité, sécurité, conformité, hébergement, infrastructure cible, méritent le même soin que les fonctionnalités. C'est souvent là que se cachent les vrais coûts et les vraies contraintes. Une cible de performance posée en chiffre, un niveau d'accessibilité visé en référence à la norme, un schéma d'hébergement qui dit où la donnée vit et qui y accède, un plan de sauvegarde et un plan de reprise quand le sujet le justifie. On ne les laisse pas en généralités floues que personne ne sait recetter. Quand un sujet dépasse ce qu'on sait traiter en interne, on le nomme et on indique l'expertise à mobiliser plutôt que de couvrir le vide par du verbiage.
Sur les projets qui passent par un appel d'offres, la SFD devient le document de référence à partir duquel les prestataires consultés vont chiffrer. C'est un usage très particulier qui change la manière de l'écrire. Tout ce qui reste flou se traduira par des écarts énormes entre les devis, par des questions en cascade pendant la phase de réponse, et par des avenants une fois le marché attribué. On rédige la SFD en pensant au prestataire qui la lit sans rien savoir du contexte, on isole ce qui est ferme de ce qui est variable, on précise les hypothèses qui sous-tendent les estimations qu'on a déjà en tête. Le document devient alors un outil de comparaison juste entre les réponses, et un repère stable pour la suite du projet.
Sur les projets internes, l'usage est différent et la forme suit. La SFD sert à aligner une équipe pluridisciplinaire autour d'une cible commune, à arbitrer les priorités, à découper le projet en lots qu'on peut livrer indépendamment. Le niveau de détail varie selon les zones : très précis là où la complexité métier est forte ou là où plusieurs équipes vont devoir se coordonner, plus ouvert là où une équipe seule peut trancher dans l'itération. Un document homogène à tout prix, où chaque écran reçoit le même traitement quel que soit son enjeu, gaspille du temps de rédaction et perd le lecteur.
Une SFD vit. C'est l'un des points sur lesquels on insiste le plus, parce que c'est celui où la pratique de marché décroche le plus souvent. Une fois le document remis, beaucoup d'agences considèrent leur travail terminé et passent à la suite. On a pris l'habitude inverse : on garde la SFD ouverte pendant tout le projet, on la révise quand un atelier de conception remonte une contrainte non anticipée, quand un développement révèle qu'une règle ne tient pas, quand un usage observé en recette demande de revoir un parcours. Le document final ressemble rarement au document initial, et c'est le signe qu'il a servi.
On assume aussi la contrepartie. Une SFD trop détaillée, écrite trop tôt, peut figer un projet dans une cible que le terrain va contredire. Il y a des contextes où on recommande plutôt un cadrage léger suivi d'un cycle itératif, où ce qu'il faut, c'est commencer à construire et apprendre, plutôt que tout poser sur papier avant de bouger. Ce choix se fait au démarrage : selon la nature du projet, le niveau d'incertitude, la culture des équipes en place, on propose la forme qui sert vraiment le résultat. Si la SFD n'est pas la bonne réponse, on le dit avant de lancer.
Le format de livraison suit la même logique. On rend un document structuré, indexé, avec une table des matières qu'on peut parcourir, des sections autoporteuses qu'on peut lire isolément, un lexique partagé pour que tout le monde appelle les choses de la même manière. Les annexes accueillent ce qui sert au pilotage sans alourdir la lecture principale : matrice des permissions, dictionnaire de données, références aux études amont, traçabilité entre exigences et règles de gestion quand le projet le demande. Selon l'usage cible, le document peut s'accompagner d'une note de synthèse à destination des décideurs, qui tient en quelques pages et reprend l'essentiel sans le diluer.
L'IA entre dans le périmètre d'une SFD le jour où elle change ce qu'on est en train de spécifier. Une fonction de recherche assistée, un assistant intégré dans un parcours, une automatisation qui prend en charge une étape jusqu'ici manuelle : ces sujets se traitent comme les autres fonctionnalités, avec leurs règles de gestion, leurs cas d'échec, leur niveau de confiance attendu, leur impact sur l'expérience utilisateur. Quand l'IA ne fait que se rajouter en surface sans déplacer la décision, on l'écarte du document plutôt que d'en faire un argument décoratif. Une SFD n'a pas vocation à vendre la technologie, elle a vocation à décrire ce qui sera construit.
Au fond, on évalue toujours une SFD à la même chose : ce qu'elle déclenche. Un document qui permet à un prestataire de chiffrer juste, à un développeur de construire sans rouvrir le sujet à chaque écran, à un opérationnel de recetter en s'appuyant dessus, est un document qui a fait son travail. Un document qui reçoit un coup de tampon en début de projet et qu'on n'ouvre plus jamais ensuite, quel que soit son volume, est un document qui a coûté son prix de rédaction et n'a rien rapporté. On écrit pour le premier cas, et on construit le projet pour qu'il y reste.