Un use case, ou cas d’utilisation, décrit une séquence d’interactions entre un acteur (utilisateur, système tiers, processus automatisé) et un système pour atteindre un objectif précis.
Ce qui change profondément, c’est le cadre dans lequel on rédige ces cas d’utilisation : contraintes réglementaires européennes, multiplication des agents autonomes et nécessité d’intégrer une analyse de risque dès la phase de définition.
Use case et EU AI Act : la classification du risque change la définition
Le fait le plus structurant pour quiconque définit un use case en 2026, c’est que la classification du risque se fait au niveau du cas d’usage, pas du modèle ou du système sous-jacent. Un même modèle de langage peut alimenter un assistant interne de rédaction (risque minimal) et un outil de présélection de candidats (risque élevé). Le niveau de risque dépend de l’intended purpose et de l’usage réel, pas de la technologie.
Cette logique, formalisée par les lignes directrices de la Commission européenne sur l’EU AI Act, impose une pratique concrète : avant de décrire les interactions acteur-système, avant même de parler de ROI, chaque use case doit inclure une analyse de risque réglementaire. Le tier de risque, les annexes concernées et l’impact sur les droits fondamentaux font désormais partie intégrante de la fiche de définition.
Pour les équipes produit et les développeurs, le changement est tangible. Un use case « high-risk » déclenche des obligations de documentation, de traçabilité des données d’entraînement et de supervision humaine que le use case « minimal risk » n’exige pas. Définir le cas d’usage sans cette couche réglementaire revient à construire sur un terrain dont on ignore le plan d’urbanisme.
Composants d’un use case en 2026 : au-delà du scénario fonctionnel
La structure classique d’un use case reste pertinente : acteurs, objectif, scénario principal, scénarios alternatifs, préconditions et postconditions. Ce squelette n’a pas changé depuis UML. Ce qui s’y ajoute en 2026, ce sont trois couches supplémentaires que la plupart des templates ignorent encore.
- Couche de classification réglementaire : tier de risque EU AI Act, annexe applicable, obligations de transparence associées. Ce bloc conditionne toute la suite du développement.
- Couche de données : origine des données d’entraînement ou de traitement, politique de conservation, conformité RGPD. Le lien entre le use case et son socle data doit être explicite dès la définition, pas ajouté après coup.
- Couche de supervision : niveau d’autonomie de l’agent ou du système, seuils de confiance en dessous desquels un humain reprend la main, fréquence d’audit. Pour les systèmes à agents autonomes, cette couche remplace le simple champ « acteur secondaire » des templates traditionnels.
Un use case complet en 2026 n’est plus un document de spécification fonctionnelle isolé. C’est un artefact transverse qui engage les équipes juridiques, data et métier dès sa rédaction.
Définir un use case pour des systèmes à agents autonomes
Les architectures multi-agents posent un problème de définition que le formalisme UML classique ne couvre pas bien. Dans un système où plusieurs agents logiciels collaborent, se délèguent des tâches et prennent des micro-décisions sans intervention humaine, la notion d’acteur unique interagissant avec un système linéaire ne tient plus.
La pratique qui émerge consiste à découper le use case en sous-cas par agent, chacun avec son périmètre d’autonomie, ses entrées-sorties et ses conditions de désescalade vers un opérateur humain. Le use case « parent » décrit l’objectif global et les règles d’orchestration. Les use cases « enfants » décrivent le comportement de chaque agent dans le contexte de cet objectif.
Cette approche hiérarchique a un avantage direct pour la conformité : elle permet d’attribuer un niveau de risque distinct à chaque sous-cas. Un agent qui résume des documents internes ne porte pas le même risque qu’un agent qui envoie des communications à des clients. Fusionner les deux dans un seul use case masquerait cette différence et compliquerait l’analyse réglementaire.
Mémoire et contexte partagé entre agents
Un point technique souvent absent des définitions : la gestion de la mémoire partagée entre agents doit figurer dans le use case. Quel agent a accès à quel historique de conversation ou de traitement ? Quelles données persistent entre deux exécutions ?
Ces questions, autrefois traitées en phase d’architecture technique, remontent désormais dans la définition du cas d’usage. Elles ont un impact direct sur la conformité données et sur le comportement attendu du système.
Pratiques à adopter pour la rédaction d’un use case en entreprise
Trois changements concrets distinguent une définition de use case solide en 2026 d’une fiche rédigée il y a deux ans.
Le premier : intégrer le marquage réglementaire avant la description fonctionnelle. Le champ « tier de risque » apparaît en tête de document, pas en annexe. Ce positionnement force les équipes à se poser la question du risque dès le cadrage, ce qui évite les requalifications tardives qui ralentissent le développement.
Le deuxième : rédiger les critères de succès en termes mesurables et auditables. « Améliorer la productivité » ne suffit pas. Un critère utile ressemble à « réduire le temps de traitement d’une demande de catégorie X de Y minutes à Z minutes, mesuré sur un échantillon de N cas sur une période donnée ». L’analyse de données post-déploiement repose sur ces critères.
Le troisième : prévoir un scénario de désactivation. Pour tout use case impliquant un modèle d’intelligence artificielle, la définition doit décrire ce qui se passe quand le système est coupé. Quel processus de repli ? Quelle perte de service acceptable ? Ce scénario, longtemps considéré comme un détail opérationnel, devient un composant attendu dans les audits de conformité.
La définition d’un use case en 2026 absorbe des contraintes qui n’existaient pas il y a trois ans. Le formalisme UML d’origine reste le point de départ, mais un cas d’utilisation qui ne couvre pas la couche réglementaire, la gouvernance des données et les conditions de supervision humaine est un document incomplet, quel que soit le soin apporté à ses scénarios fonctionnels.
