« Ça tourne, non ? » Deux semaines après le lancement en production, le traitement nocturne s'effondre parce que dix mille appareils récupèrent leurs données simultanément. Fonctionnellement, tout était correct. Personne n'avait simplement précisé quelle charge le système devait supporter. C'est ici que se décide réellement la qualité d'un logiciel : pas seulement ce qu'il fait, mais comment il le fait, dans des conditions réelles.
J'ai abordé cette question du « comment » dans plusieurs conférences. Cet article en distille les idées essentielles : ce que sont les exigences de qualité, comment les rendre mesurables avec des scénarios de qualité, comment prioriser, documenter, et ce que l'IA générative change à tout cela.
Ce que sont réellement les exigences de qualité
Les exigences fonctionnelles décrivent ce qu'un logiciel doit faire : « Le service achats déclenche une commande de réapprovisionnement. » Les exigences de qualité décrivent comment il le fait : assez vite, assez sûrement, assez facilement maintenable. Elles définissent des critères mesurables et garantissent qu'un système satisfait non seulement les utilisateurs, mais aussi les développeurs et les parties prenantes. En résumé : elles constituent une liste de contrôle contre les retouches coûteuses et les risques évitables.
Un cadre solide pour cela est la norme ISO/IEC 25010. Elle structure la qualité logicielle en huit caractéristiques principales avec de nombreuses sous-caractéristiques. Il n'est pas nécessaire de la connaître par cœur. Utilisez-la comme une carte pour qu'aucune dimension de qualité ne soit oubliée dans un projet :
| Caractéristique | Ce qu'elle couvre (exemples) |
|---|---|
| Adéquation fonctionnelle | Le logiciel fait-il les bonnes choses, complètement et correctement ? |
| Efficacité des performances | Temps de réponse, débit, consommation de ressources |
| Compatibilité | Interopérabilité avec d'autres systèmes et interfaces |
| Utilisabilité | Facilité d'apprentissage, opérabilité, accessibilité |
| Fiabilité | Disponibilité, tolérance aux pannes, récupérabilité |
| Sécurité | Confidentialité, intégrité, contrôle d'accès |
| Maintenabilité | Modularité, testabilité, réutilisabilité |
| Portabilité | Adaptabilité, installabilité, remplaçabilité |
Le point le plus important : les exigences de qualité sont plus que des exigences fonctionnelles, et pourtant ce sont elles qu'on oublie le plus souvent. Personne ne dit spontanément en session de refinement « au fait, l'interface doit répondre en moins de 200 millisecondes sous charge ». C'est quelque chose qu'il faut demander activement.
Du vœu vague au critère mesurable : les scénarios de qualité
« Le système doit être rapide et sécurisé » n'est pas une exigence, c'est un souhait. Il n'est pas vérifiable, et ce qui n'est pas vérifiable ne sera pas construit. L'outil pour le transformer en quelque chose de mesurable est le scénario de qualité (issu de la méthode ATAM). Il décrit une situation concrète et vérifiable à travers six blocs de construction :
- Source : Qui ou quoi déclenche quelque chose ?
- Stimulus : Qu'est-ce qui est exactement déclenché ?
- Environnement : Dans quelles conditions ?
- Artefacts : Quelles parties du système sont impliquées ?
- Réponse : Que doit-il se passer ?
- Mesure : Comment savoir si c'est réussi ?
Un exemple dans un contexte ERP :
Un employé des achats (source) déclenche une commande de réapprovisionnement auprès d'un fournisseur via l'interface (stimulus). C'est lundi à 11h et tous les employés utilisent le système (environnement). Sont impliqués l'interface, la base de données, le service commandes et le service entrepôt (artefacts). Le système passe la commande et signale le succès (réponse).
C'est seulement la mesure qui rend le scénario vérifiable, et ce pour plusieurs caractéristiques de qualité à la fois :
- Internationalisation : L'interface est disponible en allemand et en anglais.
- Performance : L'interface répond rapidement (ex. < 300 ms).
- Débit : Le traitement de la commande s'effectue dans les temps, même sous la charge du lundi matin.
- Sécurité : Les employés sans le rôle « Achats » ne peuvent pas passer de commande.
Chaque critère mesurable se traduit directement en approche de test : un test d'intégration pour le flux de commande, un test de charge pour le débit, un test d'autorisation pour le rôle. Un scénario, une chaîne de critères de test.
Prioriser avec le Quality Tree
Vous ne pouvez pas imposer chaque exigence avec la même rigueur, et vous ne devriez pas. Un Quality (Attribute Utility) Tree aide à trier : vous évaluez chaque scénario sur deux axes, l'importance métier et le risque ou la difficulté technique. Ce qui est important et difficile mérite un investissement. Ce qui est secondaire et simple se couvre en passant.
Cette priorisation n'est pas un exercice formel : c'est le vrai levier. Elle évite de construire une infrastructure de test pour des cas marginaux pendant que le processus métier critique reste sans tests.
Un exemple concret
Dans un projet de l'industrie des biens de consommation, l'exigence de qualité centrale est devenue limpide dès qu'on a posé la bonne question : un débit de 10 000 appareils en une heure au démarrage de chaque équipe. Ce n'est pas un vague « doit être performant », c'est un nombre contre lequel on peut tester.
L'action dérivée a suivi immédiatement : investir spécifiquement dans des tests de performance optimisés pour le débit, plutôt que de tester de façon large et non ciblée. Un seul scénario de qualité bien formulé a concentré l'ensemble de la stratégie de test.
Documenter les exigences de qualité
Un scénario qui n'existe que dans la tête d'un développeur n'est pas une exigence. Il doit être trouvable et, idéalement, lisible par les machines. Trois formats légers et éprouvés :
- arc42 : un template d'architecture libre et standardisé. Les exigences de qualité y ont leur place dédiée au chapitre 10.
- Architecture Communication Canvas (ACC) : une structure visuelle légère servant de référence pour la documentation d'architecture. Règle pratique : tout le reste est facultatif, l'ACC est obligatoire.
- Architecture Decision Records (ADRs) : un format texte épuré qui capture les décisions concrètes et leur impact sur les exigences de qualité.
L'outil importe moins que l'habitude. Plus ou moins formel, peu importe. Ce qui compte, c'est que l'exigence soit documentée, versionnée et visible par l'équipe.
La qualité à l'ère de l'IA générative
L'IA générative fait évoluer ce sujet dans deux directions qu'il convient d'examiner séparément.
L'IA comme outil. Les modèles aident à éliciter et documenter les exigences, génèrent des artefacts lisibles par les machines, produisent des diagrammes et des modèles, et accélèrent les itérations. Le vrai gain est un déplacement du focus : loin de l'effort d'écriture, vers l'évaluation. Un prompt comme « À partir de cette base de code, crée un Architecture Communication Canvas arc42 en Markdown, documente les décisions clés et les risques, et inclus un diagramme d'architecture Mermaid » fournit une première ébauche en quelques minutes — que vous affinez ensuite avec votre expertise métier.
L'IA comme composant système. Dès qu'un modèle d'IA fait partie de votre logiciel, de nouvelles exigences de qualité émergent : biais, transparence, explicabilité et robustesse. Les caractéristiques existantes comme la sécurité et les performances acquièrent également une nouvelle dimension. Vos scénarios de qualité doivent donc couvrir explicitement les risques spécifiques à l'IA, sinon vous testez un système qui se comporte fondamentalement différemment d'un logiciel traditionnel.
À faire et à éviter
Tiré de près de 20 ans de projets, voici ce qui compte vraiment :
À faire
- Exiger activement la qualité. Pour chaque exigence fonctionnelle en refinement, posez la question complémentaire : « À quelle vitesse, quel volume de données, avec quelle sécurité ? »
- Rendre mesurable. Utilisez des scénarios de qualité ou un Quality Tree. Un nombre vaut mieux qu'un adjectif.
- Questionner le domaine métier de façon critique. « À quelle fréquence ce processus se produit-il ? », « Qui utilise cette fonctionnalité ? », « Toutes ces données sont-elles vraiment nécessaires ? » Les réponses priorisent d'elles-mêmes.
- Se concentrer sur les processus cœur et les interfaces. Les décisions de performance et de sécurité se prennent généralement aux points d'intégration.
- Considérer les tests unitaires et d'intégration comme standard. Ils sont presque toujours une bonne idée et bien moins coûteux que n'importe quel incident en production.
- Sélectionner délibérément les exigences de qualité par scénario. Toutes les caractéristiques ne sont pas pertinentes ou utiles pour chaque scénario. Utilisez la liste comme guide, pas comme liste de contrôle obligatoire.
À éviter
- Ne pas se fier aux seuils de couverture de code comme mesure de qualité. Dès qu'une métrique devient un objectif, elle cesse d'être une bonne mesure (voir la loi de Goodhart). Une couverture élevée peut tout de même signifier de mauvais tests.
- Ne pas construire des tests lourds cross-système trop tôt. Ils sont coûteux et lents. Utilisez-les parcimonieusement et délibérément, pas par précaution.
- Ne pas copier la stratégie de test de quelqu'un d'autre verbatim. La bonne stratégie est spécifique au projet et émerge de vos scénarios de qualité priorisés.
- Ne pas laisser les tests gêner le travail. Si la suite de tests bloque ou ralentit chaque changement, elle sera contournée. Vous aurez alors manqué l'objectif.
- Ne pas oublier les risques spécifiques à l'IA dès qu'un modèle fait partie du système.
La qualité est une responsabilité partagée
La qualité logicielle ne naît pas d'un document ou d'un outil. Elle naît d'une attitude partagée, portée de deux côtés :
- De bas en haut, depuis le développement : exiger activement les exigences de qualité, les préciser et les documenter de façon lisible par les machines.
- De haut en bas, depuis l'architecture et le management : fournir le cadre, les outils et le soutien pour que la qualité reste visible, vérifiable et priorisée.
Commencez petit. Prenez votre processus le plus important, rédigez un seul scénario de qualité avec un nombre mesurable et dérivez-en un test. C'est plus précieux que n'importe quelle norme qui prend la poussière sur une étagère. Car au final : ce que vous ne mesurez pas, vous ne pouvez pas le promettre.