Exigences fonctionnelles et non fonctionnelles : le guide du fondateur qui paie la facture

Lundi, midi. Un fondateur ouvre les inscriptions d’une formation avec 900 personnes en liste d’attente. La page d’accueil se charge ; le paiement, non. Il a regardé la conversion de son lancement s’évaporer pendant quarante minutes.

Le studio a répondu ce qui était techniquement exact et commercialement dévastateur : « ce n’était pas dans le périmètre ». Et ça n’y était pas. Le document qu’il avait validé décrivait très bien ce que le système faisait. Il ne disait pas combien de personnes pouvaient le faire en même temps.

Les exigences fonctionnelles disent ce que le logiciel fait. Les exigences non fonctionnelles disent comment il se comporte pendant qu’il le fait : à quelle vitesse, pour combien d’utilisateurs simultanés, avec quelle disponibilité, sous quelles règles de sécurité. La différence entre exigences fonctionnelles et non fonctionnelles, c’est la différence entre un système qui passe le test et un système qui survit au lancement.

Tous les fondateurs écrivent les fonctionnelles. Presque aucun n’écrit les non fonctionnelles. Et ce sont les non fonctionnelles qui décident du prix du build, du comportement le jour du lancement et de la taille de votre perte quand quelque chose casse.

Ce que sont les exigences fonctionnelles et non fonctionnelles

Une exigence fonctionnelle est une chose que le système doit faire. Elle a un sujet, un verbe et un complément. « Le client télécharge un duplicata de facture. » Soit il le fait, soit il ne le fait pas. C’est binaire, et c’est pour ça que c’est facile à écrire, facile à tester et facile à exiger.

Une exigence non fonctionnelle est une qualité que le système doit avoir pendant qu’il fait cela. Ce n’est pas une fonction de plus ; c’est une contrainte sur toutes les fonctions. « Le duplicata s’affiche en moins de 2 secondes, pour jusqu’à 300 personnes à la fois, 99,5 % du mois. » Ce n’est pas binaire. C’est une plage, une limite, un chiffre.

La littérature académique appelle les non fonctionnelles des « attributs de qualité », et il existe une norme internationale qui les organise : l’ISO/IEC 25010, qui définit les caractéristiques de qualité d’un logiciel (performance, sécurité, fiabilité, maintenabilité et d’autres). Vous n’avez pas besoin d’apprendre la norme par cœur. Vous avez besoin de savoir qu’elle existe, parce que c’est d’elle que sort la liste des questions que personne ne vous a posées.

La confusion la plus fréquente consiste à croire que « non fonctionnel » veut dire « optionnel », ou « truc technique que le dev gère ». C’est l’inverse. Le fonctionnel est la partie que le dev gère seul, parce que vous la lui avez déjà expliquée. Le non fonctionnel est la partie qu’il va décider à votre place, en silence, si vous ne dites rien.

Trois exemples d’exigences fonctionnelles (la partie facile)

Prenons un système de rendez-vous pour un réseau de cliniques :

1. « Le patient choisit un créneau disponible dans l’agenda du praticien et confirme le rendez-vous. » Il le fait ou il ne le fait pas.
2. « Le système envoie un rappel par WhatsApp 24 heures avant la consultation. » Il le fait ou il ne le fait pas.
3. « La secrétaire déplace un rendez-vous et l’ancien créneau redevient disponible. » Il le fait ou il ne le fait pas.

C’est ce que n’importe quel fondateur peut écrire au café, et c’est ce que contient à peu près tout document d’exigences. C’est bien. C’est nécessaire. Et c’est insuffisant, parce qu’aucune de ces trois phrases ne dit ce qui se passe quand 40 secrétaires de 12 sites utilisent le système à 8 h un lundi matin, c’est-à-dire exactement quand il doit fonctionner.

Exigences non fonctionnelles : les sept questions que personne ne vous pose

Voici la liste qui remplace la norme. Sept questions. Si votre document n’y répond pas avec des chiffres, vous n’avez pas d’exigences non fonctionnelles ; vous avez de l’espoir.

1. Performance. À quelle vitesse ?
Pas « rapide ». Combien de millisecondes, sur quel écran, dans le pire des cas. La recherche de patients répond en moins de 500 ms. Le rapport mensuel peut prendre 30 secondes, et c’est très bien, tant qu’il prévient l’utilisateur qu’il travaille.

2. Charge. Pour combien en même temps ?
Le chiffre qui manquait au lancement de la formation. Combien d’utilisateurs simultanés au pic ? Et c’est quand, le pic : le jour de la paie, l’ouverture des inscriptions, le Black Friday ? Les systèmes ne tombent pas à la moyenne. Ils tombent au pic.

3. Disponibilité. Combien de temps hors service est tolérable ?
99 % d’uptime, ça sonne très bien jusqu’à ce que vous fassiez le calcul : c’est plus de 7 heures de panne par mois. 99,9 %, c’est 43 minutes. La différence entre ces deux chiffres est une décision d’architecture et de budget, et elle est à vous, pas au dev. Le SRE Book de Google est la référence pour définir cela sans deviner.

4. Sécurité et confidentialité. Qui peut voir quoi ?
Si vous traitez des données de santé, financières ou n’importe quelle donnée personnelle, respecter le RGPD n’est pas une exigence optionnelle ; c’est une obligation légale assortie d’une amende. Qui accède au dossier ? La donnée est-elle chiffrée au repos ? Existe-t-il un journal de qui a vu quoi ? C’est une exigence non fonctionnelle, et personne ne l’écrira à votre place.

5. Utilisabilité et accessibilité. Utilisable par qui ?
« La secrétaire termine une prise de rendez-vous en moins de 4 clics. » « L’app fonctionne sur Android 9, parce que la moitié de notre base est sur un vieux téléphone. » Une exigence d’utilisabilité avec un chiffre est une exigence. Sans chiffre, c’est de la décoration.

6. Maintenabilité. Qui pourra toucher à ça plus tard ?
L’exigence qui économise le plus d’argent en année 2 et que quasiment personne n’écrit. Une autre équipe peut-elle reprendre ce code ? Y a-t-il des tests automatisés ? Y a-t-il de la documentation ? Soit vous achetez un actif, soit vous achetez un otage.

7. Reprise. Et quand ça tourne mal ?
Sauvegardes tous les combien ? Combien de temps pour restaurer ? Vous acceptez de perdre les dernières 24 heures de données, ou les 5 dernières minutes ? Ces deux réponses coûtent des prix très différents, et la seule chose pire que de choisir la chère, c’est de ne pas choisir et de découvrir laquelle vous avez achetée le jour de la catastrophe.

L’exigence laissée vide n’est pas vide. Elle a une valeur par défaut.

C’est la phrase qui vaut l’article entier.

Quand vous ne précisez pas combien d’utilisateurs simultanés le système encaisse, le développeur ne laisse pas ce champ vide. Il le remplit. Et il le remplit avec la valeur la plus rapide à construire et la moins chère à faire tourner, parce que c’est ce que vous avez demandé quand vous avez demandé « le plus vite et le moins cher possible ». Il va monter une petite instance, une base sans réplica, sans file d’attente, sans cache. Et il aura raison, parce que vous n’avez rien demandé d’autre.

Idem pour les six autres. Sans exigence de disponibilité, vous avez acheté « ce qui viendra ». Sans exigence de sauvegarde, vous avez acheté « il y en a probablement une ». Sans exigence de maintenabilité, vous avez acheté un code qu’exactement une personne au monde comprend, et cette personne ne travaille pas pour vous.

Rien de tout cela n’est de la mauvaise foi du studio. C’est la conséquence mécanique d’un contrat qui ne décrit que des fonctions. Le prestataire livre ce qui est écrit, et ce qui est écrit fonctionne : le paiement de notre fondateur fonctionnait. Il a passé tous les tests. Avec un utilisateur.

C’est pour ça que la question « combien coûte une application ? » n’a presque jamais de réponse honnête avant cette conversation. Le même ensemble de fonctionnalités peut coûter 80 000 € ou 300 000 € selon les seules exigences non fonctionnelles, et nous avons déjà écrit sur pourquoi le prix d’une application dépend plus de vous que du studio.

Le test du chiffre

Si vous ne retenez qu’une chose de cet article, retenez celle-ci :

Une exigence non fonctionnelle sans chiffre n’est pas une exigence. C’est un souhait.

« Le système doit être rapide » est un souhait. « Le système doit être sécurisé » est un souhait. « Le système doit être scalable » est le plus cher de tous les souhaits, parce que ça sonne assez technique pour que tout le monde signe sans comprendre ce qu’il a acheté.

Une vraie exigence non fonctionnelle a trois parties : un chiffre, une condition et une conséquence.

Regardez ce que fait la colonne de droite : elle transforme une opinion en quelque chose qui peut être mesuré, testé et exigé. C’est la même discipline que les critères d’acceptation, appliquée aux qualités du système plutôt qu’à ses fonctions.

Et regardez la troisième partie, la conséquence. « Affiche un message d’attente au lieu d’une erreur » est une décision produit que vous seul pouvez prendre. Le dev peut vous dire combien ça coûte. Il ne peut pas vous dire ce qui est acceptable pour votre client.

Pourquoi les non fonctionnelles fixent le prix

Un studio sérieux vous facturera plus cher quand vous lui remettrez de bonnes exigences non fonctionnelles. Cela paraît contre-intuitif et c’est le meilleur signal qui soit.

La raison est simple : encaisser 800 paiements simultanés exige de l’infrastructure, des files d’attente, du cache et des tests de charge. C’est du vrai travail, et le vrai travail a un prix. Quand le devis monte après que vous avez précisé la charge, ce qui s’est passé n’est pas une augmentation. C’est la révélation du vrai prix, qui se cachait jusque-là derrière une hypothèse que personne n’avait dite à voix haute.

Le devis bon marché que vous aviez reçu avant d’écrire les non fonctionnelles n’était pas moins cher. C’était le même produit, avec le risque transféré chez vous.

C’est d’ailleurs la meilleure façon de comparer des propositions. Envoyez les sept chiffres à trois studios. Celui qui renvoie le même prix qu’avant ne les a pas lus. Celui qui monte le prix et explique ligne par ligne où ça monte, c’est celui-là que vous voulez à la table.

Où l’exigence non fonctionnelle devient une obligation

Un chiffre qui vit dans un Google Doc ne protège personne. Il doit traverser trois documents pour devenir une obligation :

Dans le recueil des exigences, il naît. C’est là que vous découvrez qu’il y a un pic à 8 h et que la moitié de la base est sur un vieil Android. Ce travail est le vôtre, et nous avons déjà détaillé comment rédiger un document d’exigences logicielles sans être technique.

Dans le critère d’acceptation, il devient un test. « Test de charge avec 800 sessions simultanées, exécuté avant le go-live » est une ligne qui transforme une promesse en un événement vérifiable, avec une date.

Dans le contrat, il devient une conséquence. Une exigence non fonctionnelle qui n’apparaît pas dans le contrat de développement logiciel est une conversation de couloir. Si la disponibilité contractuelle est de 99,5 % et que le système en livre 97 %, que se passe-t-il ? Si la réponse est « on en discutera », vous n’avez pas une exigence. Vous avez un sujet.

Le fondateur de la formation n’a pas raté son lancement parce qu’il avait recruté des incompétents. Il l’a raté parce qu’il a acheté un système qui faisait tout ce qu’il avait demandé, et il n’a jamais demandé qu’il fonctionne pour 900 personnes à la fois. Le document était juste. Il était seulement à moitié écrit.

Questions fréquentes

Que sont les exigences fonctionnelles ?
Ce sont les fonctions que le système doit exécuter : ce qu’il fait. « L’utilisateur réinitialise son mot de passe par e-mail », « le gestionnaire exporte le rapport en CSV ». Elles ont une réponse binaire : le système le fait ou ne le fait pas. C’est la partie du périmètre que presque tout fondateur sait écrire seul.

Que sont les exigences non fonctionnelles ?
Ce sont les qualités et les contraintes qui valent pour tout le système : à quelle vitesse, pour combien d’utilisateurs simultanés, avec quelle disponibilité, avec quel niveau de sécurité, avec quelle facilité de maintenance, avec quel plan de reprise. Elles ne décrivent pas une fonction de plus ; elles décrivent le comportement de toutes les fonctions sous pression. Ce sont les exigences qui décident du prix du build et du résultat du jour de lancement.

Quelle est la différence entre exigence fonctionnelle et non fonctionnelle ?
La fonctionnelle, c’est quoi ; la non fonctionnelle, c’est à quel point. « Émettre la facture » est fonctionnel. « Émettre la facture en moins de 3 secondes, pour 500 commandes simultanées, avec 99,5 % de disponibilité » ajoute les non fonctionnelles. La fonctionnelle détermine si le logiciel sert ; la non fonctionnelle détermine s’il tient.

Quels sont 3 exemples d’exigences fonctionnelles ?
(1) « Le patient choisit un créneau disponible et confirme le rendez-vous. » (2) « Le système envoie un rappel par WhatsApp 24 heures avant la consultation. » (3) « La secrétaire déplace un rendez-vous et l’ancien créneau redevient disponible. » Chacune décrit une action concrète du système, avec une réponse binaire.

Quels sont les types d’exigences non fonctionnelles ?
Celles qui comptent pour qui commande un build sont au nombre de sept : performance (à quelle vitesse), charge (pour combien en même temps), disponibilité (combien de panne est tolérable), sécurité et confidentialité (qui voit quoi, et quelle réglementation s’applique), utilisabilité et accessibilité (utilisable par qui, sur quel appareil), maintenabilité (qui pourra reprendre le code plus tard) et reprise (sauvegardes et temps de restauration).

Qui écrit les exigences non fonctionnelles : moi ou le studio ?
Les chiffres sont à vous ; l’architecture est au studio. Vous seul savez que le pic est à 8 h, que perdre 24 heures de données est inacceptable et que la moitié de vos utilisateurs sont sur un vieux téléphone. Comment livrer cela est le problème de celui qui construit. L’erreur classique consiste à externaliser la question en même temps que la réponse, puis à découvrir, le jour du lancement, quelle valeur par défaut vous avez achetée sans le savoir.