Des cas d’usage IA à une décision de pilote cadrée

Un cas d’usage n’est pas encore une décision de pilote

Un cas d’usage nomme une application possible. Une preuve de concept vérifie surtout si un mécanisme technique peut fonctionner. Un pilote observe si un système sociotechnique peut opérer dans un workflow réel et borné. Passer de l’un à l’autre exige une décision, pas une liste d’idées plus longue.

AURA commence donc par une décision métier importante mais suffisamment limitée pour rester corrigible. L’équipe doit savoir qui peut autoriser, suspendre et arrêter le test, quelle tâche est observée, qui peut être affecté et quelle preuve ferait réellement évoluer la décision.

PILOT, PREPARE, REDESIGN, CONSOLIDATE, PAUSE et STOP sont des états de décision AURA, non des catégories réglementaires. Une décision STOP peut créer de la valeur lorsqu’elle évite un engagement plus coûteux et insuffisamment étayé.

Les huit conditions d’un pilote IA cadré

Un pilote devient décisionnel lorsque ses limites commerciales, opérationnelles, humaines et data sont visibles avant le test. Ces conditions ne certifient ni sécurité ni conformité ; elles rendent l’incertitude suffisamment explicite pour une revue responsable.

• Une décision métier et un responsable humain habilité à suspendre ou arrêter.
• Un workflow observable plutôt qu’une ambition générale comme « utiliser l’IA dans les ventes ».
• Des tâches, utilisateurs, données et conséquences explicitement inclus et exclus.
• Des données autorisées, pertinentes et disponibles, avec provenance comprise.
• Une baseline décrivant le processus actuel avant l’intervention IA.
• Des mesures d’acceptation et garde-fous définis avant l’observation des résultats.
• Des voies de revue, d’override, de correction et d’escalade humaines réellement opérantes.
• Une date de revue, des conditions d’arrêt et un retour viable au processus précédent.

Le Bounded Pilot Canvas d’AURA

Complétez ce canvas avant de choisir un outil ou un fournisseur. Si un champ reste sans réponse, la prochaine décision est généralement PREPARE plutôt que PILOT. Ce canvas est un instrument de travail AURA, pas un avis juridique, une certification ou le substitut d’une évaluation sectorielle.

Mesurer une preuve, pas promettre un ROI

Le NIST AI Risk Management Framework organise la gestion du risque autour de Govern, Map, Measure et Manage. Son playbook Measure recommande des métriques adaptées au contexte, des limites de performance acceptables et la documentation de ce qui n’est pas mesuré. AURA s’inspire de cette discipline sans revendiquer de certification NIST.

Un pilote doit séparer trois questions : la sortie a-t-elle performé dans le contexte testé, les risques sont-ils restés dans les tolérances et l’organisation peut-elle exploiter les contrôles de manière fiable ? Une réponse positive à une question ne répond pas aux deux autres.

Partez d’une baseline, définissez un signal opérationnel principal et consignez erreurs, incidents, quasi-incidents, overrides et observations manquantes. Un résultat positif n’étaye que la décision écrite dans le pilote ; il n’établit automatiquement ni ROI, adoption, conformité, sécurité ni aptitude à l’échelle.

Concevoir la voie humaine avant la voie automatisée

La supervision humaine n’est pas un nom sur une slide. La personne désignée doit comprendre les limites du système, reconnaître une anomalie, ignorer ou inverser une sortie si nécessaire, interrompre l’usage et escalader un incident. Ces contrôles doivent être testés dans les mêmes conditions opérationnelles que le pilote.

La réversibilité signifie que l’organisation peut suspendre le test, revenir au processus antérieur, conserver la trace des preuves et examiner ce qui s’est passé sans exposer les personnes ou les opérations à un dommage disproportionné. Si le processus antérieur ne peut pas être restauré, l’initiative est peut-être déjà trop large pour un premier pilote.

• Tester l’override et le fallback au lieu de supposer leur existence.
• Consigner quand l’humain accepte, modifie, rejette ou ne peut évaluer une sortie.
• Donner au responsable de l’arrêt l’autorité, le temps et l’information nécessaires.
• Inclure incidents et quasi-incidents dans la fiche finale.

Ce que les organisations suisses doivent vérifier en 2026

La législation suisse sur la protection des données s’applique déjà aux traitements de données personnelles impliquant l’IA. Le PFPDT met en avant la transparence sur la finalité, le fonctionnement et les sources de données, ainsi qu’une analyse d’impact lorsqu’un traitement projeté présente vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux.

La Suisse ne repose pas encore sur une loi générale unique consacrée à l’IA. Les règles existantes en matière de données, emploi, non-discrimination, propriété intellectuelle, confidentialité, consommation et secteurs régulés peuvent néanmoins s’appliquer. Les organisations actives sur le marché européen doivent évaluer séparément l’AI Act, leur rôle et la classification juridique du système concret.

Ce guide signale des questions ; il ne détermine ni juridiction, ni classe de risque, ni conformité. Une revue juridique spécialisée constitue un workstream séparé lorsque le contexte le justifie. Un hébergement en Suisse ne rend pas à lui seul un système sûr, souverain ou conforme.

Clore avec une fiche de décision d’une page

Le pilote se termine lorsque la coalition responsable prend une décision, pas lorsqu’une démonstration semble convaincante. La fiche doit préciser date, sponsor, process owner, périmètre testé, preuves obtenues, limites, incidents, risques résiduels, état choisi, prochaine preuve, responsable et échéance.

Les décisions PAUSE et STOP doivent aussi indiquer quelles nouvelles conditions permettraient de rouvrir la question. Le choix reste ainsi contestable et révisable sans transformer chaque idée écartée en backlog indéfini.