Comprendre les systèmes autonomes avant de parler d’automatisation.
Un parcours local en six étapes : systèmes autonomes, actions automatisées, contrôle avant exécution, POM-RX, sécurité et gouvernance, puis blockchain comme domaine de recherche complémentaire.
Ces modules expliquent des concepts et des limites. Ils ne prouvent aucun déploiement, blocage d’action, audit, certification, résultat réel ou niveau de maîtrise.
Voir le parcoursSix parcours
Du cycle d’action à la décision gouvernée.
Chaque parcours contient deux leçons, une question avec retour contextualisé et au moins une activité guidée locale.
- 01 · 01 · Fondations
Systèmes autonomes
Distinguer automatisation, système autonome et agent, puis lire tout le cycle d’une action.
Ouvrir le parcours - 02 · 02 · Décision
Contrôle avant exécution
Transformer intention et contexte en décision explicite, puis s’arrêter si une condition manque.
Ouvrir le parcours - 03 · 03 · Reçus structurels
POM-RX
Lire les trois reçus publics et leurs contrôles sans élargir ce qu’ils démontrent.
Ouvrir le parcours - 04 · 04 · Menaces et identité
Sécurité
Protéger secrets, identité et contexte de confiance, puis reconnaître les menaces propres aux actions d’agents.
Ouvrir le parcours - 05 · 05 · Registre partagé
Blockchain
Comprendre registre, consensus et frontières de réseau sans confondre inscription et vérité.
Ouvrir le parcours - 06 · 06 · Responsabilité
Gouvernance
Relier politiques, rôles et responsabilités, puis documenter décisions, exceptions, incidents et revues.
Ouvrir le parcours
Glossaire trilingue
Un vocabulaire stable, avec ses invariants et ses limites.
Chaque terme conserve le même identifiant en français, anglais et espagnol. La définition borne son usage dans ce Learning Hub.
Système autonomeautonomous-system
Système qui peut sélectionner ou enchaîner des actions dans un périmètre défini.
Invariants
- • Les objectifs, règles et contexte bornent le périmètre décrit.
- • Le terme décrit une capacité de système, pas une personne.
À éviter
- • Une intention propre ou une conscience.
- • Une garantie de sûreté ou de qualité.
Limite de sens
Le terme ne prouve pas qu’un système est déployé ni que ses actions sont correctes.
Agent logicielsoftware-agent
Composant logiciel qui agit selon des instructions, des outils et un contexte disponibles.
Invariants
- • Un agent reste un composant technique identifié par son périmètre.
- • Ses entrées et sorties doivent être distinguées des faits externes.
À éviter
- • Une identité humaine.
- • Une autonomie sans limites.
Limite de sens
Le mot agent ne démontre ni responsabilité juridique ni comportement fiable.
Action automatiséeautomated-action
Action produite par une règle, un logiciel ou un flux sans intervention manuelle à chaque étape.
Invariants
- • La règle ou le flux qui la produit doit être décrit séparément.
- • Une action déclarée doit rester distincte d’une action observée.
À éviter
- • Une action forcément autorisée.
- • Une exécution correcte ou irréversible.
Limite de sens
Le terme ne confirme pas que l’action a eu lieu dans le monde extérieur.
Intention déclaréedeclared-intent
Entrée fournie qui décrit l’action envisagée ou demandée.
Invariants
- • Elle doit être traitée comme une donnée fournie.
- • Elle peut être comparée à une politique ou à un contexte disponible.
À éviter
- • Une preuve de l’intention réelle.
- • L’usage effectif d’une autorisation.
Limite de sens
Elle ne prouve ni l’auteur réel, ni l’exécution, ni le résultat de l’action.
Contexte évaluéevaluated-context
Ensemble d’attributs disponibles au moment où une règle ou une décision est examinée.
Invariants
- • La source, la fraîcheur et la qualité des attributs doivent être qualifiées.
- • Un contexte est une vue bornée, pas le monde complet.
À éviter
- • Des faits externes automatiquement vrais.
- • Une chronologie de confiance.
Limite de sens
Le contexte ne vaut que pour les données et le moment explicitement indiqués.
Politique de contrôlecontrol-policy
Règle ou ensemble de règles utilisé pour évaluer une situation décrite.
Invariants
- • La politique doit être distinguée de son application effective.
- • Ses entrées, sorties et exceptions doivent être explicites.
À éviter
- • Une preuve que le contrôle est appliqué.
- • Une garantie de conformité.
Limite de sens
La présence d’une politique ne démontre ni enforcement ni qualité de décision.
Décision d’autorisationauthorization-decision
Résultat de modèle tel que permettre, refuser ou non résolu pour des entrées données.
Invariants
- • La décision doit nommer les entrées et la règle utilisées.
- • Une décision peut rester non résolue si la preuve est insuffisante.
À éviter
- • L’usage effectif d’une autorisation.
- • Le blocage réel d’une action.
Limite de sens
Le résultat ne démontre pas qu’un système d’exécution l’a respecté.
Contrôle avant exécutionpre-execution-control
Étape conceptuelle où une action décrite est évaluée avant une exécution éventuelle.
Invariants
- • Le contrôle porte sur des entrées disponibles et une règle définie.
- • La décision et l’exécution doivent rester séparées dans les preuves.
À éviter
- • Un contrôle opérationnel déjà branché.
- • Une preuve que l’action a été empêchée.
Limite de sens
Cette notion ne revendique pas un mécanisme déployé ni un effet réel.
Validation humainehuman-review
Intervention explicite d’une personne pour valider, refuser, examiner ou escalader un cas.
Invariants
- • Le rôle, le moment et la portée de la revue doivent être indiqués.
- • Une revue peut conclure à plus d’information ou à un refus.
À éviter
- • Une approbation automatique.
- • Une garantie de qualité ou de responsabilité.
Limite de sens
La revue ne vaut que pour son périmètre et sa trace documentée.
Fail-closedfail-closed
Principe de conception qui préfère ne pas poursuivre lorsque les conditions requises ne sont pas établies.
Invariants
- • Les conditions manquantes doivent être explicites.
- • Un résultat non résolu reste distinct d’un succès.
À éviter
- • Une preuve de déploiement réel.
- • Une garantie contre tout risque.
Limite de sens
Le principe ne prouve pas qu’un système concret bloque effectivement une action.
Traçabilitétraceability
Capacité à relier des entrées, décisions ou artefacts selon une méthode déclarée.
Invariants
- • Les liens doivent indiquer leur méthode et leur portée.
- • Une trace doit être distinguée de l’événement qu’elle décrit.
À éviter
- • La vérité d’un fait externe.
- • Une chronologie automatiquement fiable.
Limite de sens
La traçabilité dépend de la qualité et des limites des données reliées.
Vérifiabilitéverifiability
Possibilité d’inspecter une structure ou une règle avec une méthode définie.
Invariants
- • La méthode, les entrées et les limites doivent être visibles.
- • Vérifier une structure est différent de vérifier le monde extérieur.
À éviter
- • Une authenticité ou une vérité implicite.
- • Un audit indépendant.
Limite de sens
La vérifiabilité est limitée à ce que la méthode contrôle effectivement.
Reçu fournisupplied-receipt
Enregistrement présenté à un vérificateur comme donnée d’entrée.
Invariants
- • Le reçu doit être décrit comme fourni, pas observé indépendamment.
- • Son format et ses liens peuvent être inspectés.
À éviter
- • Une preuve que l’événement a eu lieu.
- • Une source authentifiée.
Limite de sens
Un reçu fourni ne prouve pas sa provenance, sa date réelle ni son effet.
Contrôle structurelstructural-check
Inspection de la forme, des champs ou des liens d’un artefact fourni.
Invariants
- • Le contrôle doit annoncer les règles testées.
- • Un rejet structurel ne qualifie pas le fait décrit.
À éviter
- • Une validation de l’action réelle.
- • Un contrôle de sécurité complet.
Limite de sens
Le contrôle se limite aux propriétés de structure qu’il implémente.
Provenance du contenucontent-provenance
Référence au dépôt, au commit et à la version qui ont produit une leçon locale.
Invariants
- • Elle identifie le contenu pédagogique local.
- • Elle reste séparée des autorités externes citées par la leçon.
À éviter
- • Une source externe officielle.
- • Une validation de la justesse du contenu.
Limite de sens
Elle ne prouve que l’origine versionnée du contenu local.
Source externeexternal-source
Publication ou artefact public cité pour borner une affirmation pédagogique.
Invariants
- • La source doit avoir un identifiant stable, une URL et une date de vérification.
- • La portée citée et ses limites doivent être adjacentes.
À éviter
- • Une approbation de SwissTokint.
- • Une preuve d’implémentation locale.
Limite de sens
La citation ne soutient que la formulation explicitement bornée.
Frontière de preuveevidence-boundary
Limite explicite entre ce qu’une source démontre et ce qu’elle ne démontre pas.
Invariants
- • Chaque claim doit rester dans la portée identifiée.
- • Les inférences interdites doivent être visibles.
À éviter
- • Une absence de limite.
- • Une extension implicite de portée.
Limite de sens
La frontière doit être revue quand la source, la version ou le contexte change.
POM-RX v0.1pom-rx
Spécification de travail publique et prototype testé pour des contrôles structurels de reçus fournis.
Invariants
- • La version, le commit public et les limites doivent être adjacents.
- • La portée publique se limite au schéma, au vérificateur Node/TypeScript et à la suite de sept tests.
À éviter
- • Un produit en production.
- • Une preuve de vérité, de sécurité ou de blocage d’exécution.
Limite de sens
POM-RX v0.1 ne démontre ni authenticité, ni chronologie fiable, ni observation indépendante.
Concept candidat DAGRdagr
Concept candidat de recherche avancée présenté dans le Learning Hub.
Invariants
- • Son statut candidat doit rester visible.
- • Aucune spécification publique ni implémentation publique n’est référencée ici.
À éviter
- • Une note publiée.
- • Une implémentation, un standard, un produit ou une capacité opérationnelle.
Limite de sens
Le terme ne revendique aucune capacité opérationnelle ni maturité publique.
Secretsecret
Valeur confidentielle utilisée pour authentifier, signer ou protéger un accès.
Invariants
- • Un secret ne doit pas être rendu dans le client, les logs ou les exemples.
- • Sa rotation et sa portée sont des décisions opérationnelles.
À éviter
- • Une simple étiquette ou un identifiant public.
- • Une valeur partageable pour tester.
Limite de sens
La présence d’un nom de variable ne révèle ni la valeur ni sa validité.
Identitéidentity
Information utilisée pour distinguer un sujet dans un système donné.
Invariants
- • Le système et le niveau de preuve doivent être précisés.
- • Une identité doit être séparée de ses attributs et permissions.
À éviter
- • Une preuve certaine de la personne réelle.
- • Une autorisation automatique.
Limite de sens
La signification est limitée au mécanisme d’identité décrit.
Moindre privilègeleast-privilege
Principe consistant à limiter les permissions au besoin identifié.
Invariants
- • Le besoin et la portée de permission doivent être explicites.
- • Les permissions doivent pouvoir être revues.
À éviter
- • Une garantie qu’aucun abus n’est possible.
- • Une preuve de conformité.
Limite de sens
Le principe ne prouve pas que toutes les permissions réelles sont minimales.
Modèle de menacethreat-model
Méthode pour décrire des actifs, acteurs, chemins d’attaque et conséquences possibles.
Invariants
- • Les hypothèses et le périmètre doivent être écrits.
- • Un modèle de menace doit être revu lorsque le système change.
À éviter
- • Une liste exhaustive de risques.
- • Une garantie de sécurité.
Limite de sens
Il éclaire une analyse, sans démontrer que les risques sont éliminés.
Contrôle d’accèsaccess-control
Mécanisme ou règle qui détermine l’accès demandé à une ressource.
Invariants
- • Le sujet, la ressource, l’action et le contexte doivent être distingués.
- • La décision doit être séparée de son enforcement observé.
À éviter
- • Une preuve que l’accès est effectivement empêché.
- • Une authentification à elle seule.
Limite de sens
Le terme dépend du mécanisme précis qui est documenté.
Zero Trustzero-trust
Approche qui évite de traiter implicitement un emplacement ou un réseau comme fiable.
Invariants
- • Les décisions d’accès sont liées aux ressources et au contexte.
- • La vérification doit être pensée comme continue et bornée.
À éviter
- • Un produit unique.
- • Une sécurité totale.
Limite de sens
Le terme décrit une architecture de référence, pas une conformité démontrée.
Registre partagéshared-ledger
Ensemble d’enregistrements répliqués ou synchronisés selon les règles d’un réseau.
Invariants
- • Les règles du réseau déterminent ce qui est vérifiable.
- • Le registre doit être distingué des faits qu’il référence.
À éviter
- • Une vérité automatique du monde extérieur.
- • Une nécessité pour chaque problème.
Limite de sens
Le registre ne prouve que les propriétés rendues possibles par ses règles.
Réseau blockchainblockchain-network
Réseau qui applique des règles de validation, de réplication et de consensus à un registre.
Invariants
- • Le réseau, ses règles et ses participants doivent être distingués.
- • Une blockchain est un type de système de registre, pas le contenu du registre.
À éviter
- • Une garantie légale ou économique.
- • Une solution universelle.
Limite de sens
Les propriétés dépendent de la conception et des règles du réseau précis.
Consensusconsensus
Processus par lequel un réseau applique ses règles pour accepter ou ordonner certains enregistrements.
Invariants
- • Le mécanisme et ses hypothèses doivent être nommés.
- • Le consensus du réseau est distinct de la vérité d’un fait externe.
À éviter
- • Une garantie absolue contre toute erreur.
- • Une preuve de légalité.
Limite de sens
Le terme se limite aux règles et au modèle de menace du réseau concerné.
Contrat intelligentsmart-contract
Programme exécuté selon les règles d’une plateforme, souvent appelé smart contract.
Invariants
- • Le code, le réseau et les entrées doivent être distingués du contrat juridique.
- • Le comportement dépend des règles et de l’état de la plateforme.
À éviter
- • Un contrat juridique automatiquement valide.
- • Une garantie de sécurité ou de résultat.
Limite de sens
Le terme décrit un programme et ne qualifie pas sa validité juridique.
Gouvernancegovernance
Organisation des rôles, règles, décisions, exceptions et revues autour d’un système ou d’une activité.
Invariants
- • Les rôles et responsabilités doivent être explicitement attribués.
- • Les exceptions et incidents doivent avoir un chemin de revue.
À éviter
- • Une certification.
- • Une preuve que les décisions sont justes.
Limite de sens
La gouvernance décrite ne prouve pas à elle seule son application effective.
Exceptionexception
Cas qui ne suit pas la règle ordinaire et nécessite un traitement explicite.
Invariants
- • L’exception doit indiquer son motif, sa portée et sa revue.
- • Elle doit rester traçable et limitée dans le temps si nécessaire.
À éviter
- • Une façon silencieuse de contourner une politique.
- • Une autorisation générale.
Limite de sens
Une exception ne modifie pas automatiquement la règle de base.
Incidentincident
Événement ou signal qui exige une évaluation, une réponse ou une revue documentée.
Invariants
- • La portée, les faits connus et les actions prises doivent être séparés.
- • La réponse doit éviter de divulguer des données sensibles.
À éviter
- • Une preuve complète de cause.
- • Une garantie qu’un incident ne se reproduira pas.
Limite de sens
Un incident reste borné aux informations vérifiées et au processus documenté.
Automatisationautomation
Exécution répétable d’une opération selon une règle ou un flux défini.
Invariants
- • Le déclencheur et la règle doivent être identifiables.
- • Le résultat reste distinct de l’intention.
À éviter
- • Un choix autonome sans règles.
- • Une preuve d’intelligence ou de sûreté.
Limite de sens
Le terme ne prouve ni déploiement, ni autorisation, ni résultat réel.
Agent IAai-agent
Agent logiciel dont certaines sélections ou inférences utilisent une méthode d’IA.
Invariants
- • Il reste un composant logiciel borné.
- • Ses permissions restent séparées de ses capacités.
À éviter
- • Toute IA.
- • Une personne ou une autorité autonome.
Limite de sens
Le terme ne démontre ni fiabilité, ni responsabilité juridique, ni capacité opérationnelle.
Actionaction
Opération demandée, autorisée, déclenchée ou observée à une étape donnée.
Invariants
- • Son statut doit être précisé.
- • Action déclarée et action observée restent distinctes.
À éviter
- • Une intention.
- • Une preuve automatique de résultat.
Limite de sens
Le mot seul ne confirme pas que l’opération s’est produite hors du système décrit.
Intentionintent
Représentation de l’action envisagée ou demandée.
Invariants
- • Elle constitue une entrée à évaluer.
- • Sa source et sa portée doivent être indiquées.
À éviter
- • Une autorisation.
- • Une action ou un résultat observé.
Limite de sens
Une intention ne prouve ni son auteur réel, ni son exécution, ni son issue.
Contextecontext
Attributs disponibles autour d’une intention, d’une règle ou d’une décision.
Invariants
- • La source, la date et la fraîcheur doivent être qualifiées.
- • Un contexte peut être incomplet.
À éviter
- • Une vérité exhaustive.
- • Une permission implicite.
Limite de sens
Le contexte ne vaut que pour les attributs et le moment explicitement documentés.
Politiquepolicy
Ensemble versionné de règles et de responsabilités pour décider dans un périmètre.
Invariants
- • Propriétaire, version et autorité de modification doivent être explicites.
- • La politique reste distincte de son application.
À éviter
- • Une préférence informelle.
- • Une preuve d’enforcement.
Limite de sens
Une politique obsolète ou incomplète peut produire une décision incorrecte.
Règlerule
Condition déclarée qui relie des entrées à une décision ou une sortie.
Invariants
- • Entrées, logique, version et sortie doivent être identifiables.
- • Une règle appartient à un périmètre défini.
À éviter
- • Une politique complète.
- • Une preuve que la règle est appliquée.
Limite de sens
La règle décrite ne démontre ni sa qualité ni son enforcement effectif.
Preflightpreflight
Première phase POM-RX fournie, avec une conclusion déclarée `allow` ou `deny` et ses assertions.
Invariants
- • Il précède l’accusé d’exécution.
- • Il reste un reçu fourni.
À éviter
- • Une action exécutée.
- • Une vérité externe ou un blocage démontré.
Limite de sens
Le preflight ne confirme pas à lui seul un fait externe ni l’usage effectif de la décision.
Autorisationauthorization
Décision explicite permettant une action dans une portée, une durée et un contexte définis.
Invariants
- • La décision doit être attribuée et révocable.
- • Elle précède l’action autorisée.
À éviter
- • Une permission générale.
- • Une preuve d’exécution ou de résultat.
Limite de sens
L’autorisation ne confirme pas que l’action a été tentée, exécutée ou réussie.
Allowallow
Sortie de décision qui permet de poursuivre dans la portée évaluée.
Invariants
- • La portée et les conditions doivent rester attachées.
- • La décision peut être révoquée.
À éviter
- • Une autorisation universelle.
- • Une exécution ou un succès.
Limite de sens
`Allow` ne démontre pas que le système d’exécution a respecté la décision.
Denydeny
Sortie de décision qui ne permet pas de poursuivre dans le contexte évalué.
Invariants
- • Le motif et les entrées doivent rester traçables.
- • Une condition manquante peut conduire à ce résultat.
À éviter
- • Une sanction générale.
- • Une preuve de blocage physique.
Limite de sens
`Deny` ne confirme pas qu’un mécanisme externe a effectivement empêché l’action.
Reviewreview
Sortie demandant un examen explicite avant toute nouvelle décision.
Invariants
- • Le dossier reste non autorisé tant que la revue n’a pas conclu.
- • Le rôle et l’issue doivent être documentés.
À éviter
- • Une approbation par défaut.
- • Un simple délai.
Limite de sens
`Review` ne vaut ni `allow`, ni validation humaine déjà obtenue.
Accusé d’exécutionexecution-acknowledgement
Deuxième phase POM-RX fournie, avec un résultat `accepted`, `rejected` ou `unresolved` relié au preflight.
Invariants
- • Le lien au preflight doit rester contrôlable.
- • POM-RX ne réalise pas l’action.
À éviter
- • Une observation indépendante.
- • Une preuve de succès ou d’exécution réelle.
Limite de sens
L’accusé fourni ne confirme ni authenticité, ni chronologie fiable, ni fait externe.
Observationobservation
Information rapportée ou recueillie au sujet d’un état après une action envisagée.
Invariants
- • La source, le moment et la méthode doivent être qualifiés.
- • Elle reste distincte de l’intention.
À éviter
- • Une vérité automatiquement fiable.
- • Une réconciliation déjà effectuée.
Limite de sens
Une observation non indépendante ou non vérifiée ne prouve pas le fait externe décrit.
Réconciliationreconciliation
Comparaison documentée entre état attendu et état observé, avec un résultat borné.
Invariants
- • Les issues peuvent rester `matched`, `mismatched` ou `unresolved`.
- • Les inconnues doivent rester visibles.
À éviter
- • Une correction automatique.
- • Une preuve exhaustive du monde extérieur.
Limite de sens
La réconciliation ne dépasse pas les sources, données et méthodes comparées.
Reçureceipt
Enregistrement structuré fourni pour décrire une phase, des entrées et une sortie.
Invariants
- • Schéma, version et liens doivent être identifiables.
- • Le reçu reste distinct de l’événement décrit.
À éviter
- • Une preuve automatique d’authenticité.
- • Une observation indépendante.
Limite de sens
Un reçu fourni ne confirme que les propriétés effectivement contrôlées de sa structure.
Preuveproof
Élément qui soutient une affirmation précise selon une source et une méthode identifiées.
Invariants
- • Affirmation, source, méthode et limite doivent être adjacentes.
- • La force de preuve dépend du périmètre.
À éviter
- • Une vérité universelle.
- • Une certification implicite.
Limite de sens
Une preuve ne soutient pas les affirmations que sa méthode ne contrôle pas.
Empreintefingerprint
Valeur compacte dérivée de données par une méthode déclarée.
Invariants
- • La méthode et les octets d’entrée doivent être définis.
- • Une modification peut produire une empreinte différente.
À éviter
- • L’identité de l’auteur.
- • La vérité ou la qualité des données.
Limite de sens
Une empreinte permet une comparaison technique, pas une validation du contenu.
Lien de hachagehash-link
Relation où un objet référence l’empreinte calculée d’un objet précédent.
Invariants
- • Méthode, représentation canonique et ordre doivent être précisés.
- • La correspondance peut être contrôlée structurellement.
À éviter
- • Une chronologie fiable.
- • Une preuve d’authenticité ou d’exécution.
Limite de sens
Le lien établit une relation entre objets fournis, pas la vérité de leurs déclarations.
Fait externeexternal-fact
Affirmation concernant une personne, un système ou un événement hors des objets fournis.
Invariants
- • Une source indépendante adaptée doit être recherchée.
- • Le fait reste distinct de sa représentation.
À éviter
- • Une donnée automatiquement vraie parce qu’elle est enregistrée.
- • Une conclusion tirée du seul reçu.
Limite de sens
La structure d’un reçu ou d’un registre ne confirme pas à elle seule le fait externe.
Registre distribuédistributed-ledger
Registre dont des participants répliquent ou synchronisent l’état selon des règles communes.
Invariants
- • Participants, règles et modèle de confiance doivent être nommés.
- • Le réseau reste distinct des données et applications.
À éviter
- • Une blockchain nécessairement publique.
- • Une solution nécessaire à chaque usage.
Limite de sens
Le registre ne prouve ni vérité externe, ni finalité universelle, ni adéquation du cas d’usage.
Finalitéfinality
Propriété définie par un protocole pour qualifier la stabilité d’un état ou d’un ordre observé.
Invariants
- • Le réseau, les règles et le moment doivent être indiqués.
- • Les hypothèses varient selon le protocole.
À éviter
- • Une irréversibilité universelle.
- • Une validité juridique ou une vérité externe.
Limite de sens
La finalité ne vaut que dans le modèle et le contexte d’observation documentés.
Ancrageanchoring
Enregistrement d’un engagement ou d’une empreinte dans un système de registre.
Invariants
- • Le réseau, la méthode et le moment doivent être précisés.
- • L’empreinte reste distincte de la donnée source.
À éviter
- • Une validation de la vérité du contenu.
- • Une preuve de l’auteur ou de permission.
Limite de sens
L’ancrage soutient une relation technique bornée, pas la vérité ou la légalité de la donnée.
Dérogationderogation
Exception explicitement autorisée à une règle pour une portée et une durée définies.
Invariants
- • Autorité, motif, portée, durée et revue doivent être tracés.
- • Elle doit pouvoir expirer ou être révoquée.
À éviter
- • Un contournement informel.
- • Une requalification rétroactive d’un incident.
Limite de sens
Une dérogation ne modifie pas automatiquement la politique générale.
Progression localelocal-progress
État enregistré dans le navigateur pour aider à reprendre un parcours pédagogique.
Invariants
- • La persistance est locale et soumise au consentement explicite.
- • L’effacement et les erreurs de stockage doivent être visibles.
À éviter
- • Un compte utilisateur.
- • Un suivi analytique ou une qualification.
Limite de sens
La progression n’est qu’un état d’interaction locale.
Leçon terminéelesson-completion
État indiquant que l’interaction locale prévue pour une leçon a été accomplie.
Invariants
- • La condition de complétion doit être explicite.
- • La complétion reste distincte du score et de la maîtrise.
À éviter
- • Une certification.
- • Une aptitude opérationnelle.
Limite de sens
Cet état ne prouve qu’une interaction locale terminée.
NO-GOno-go
Décision contrôlée de ne pas poursuivre tant que les conditions requises ne sont pas satisfaites.
Invariants
- • Les conditions manquantes et le propriétaire de la décision doivent être explicites.
- • Un NO-GO ne doit pas être transformé en succès implicite.
À éviter
- • Un échec personnel.
- • Une autorisation différée automatique.
Limite de sens
Le statut s’applique seulement au périmètre et au moment documentés.
Prototype testéprototype
Artefact expérimenté dans la portée de tests explicitement indiquée.
Invariants
- • Les tests, la version et les limites doivent être adjacents.
- • Un prototype reste distinct d’un produit mature.
À éviter
- • Une disponibilité générale.
- • Une certification ou un audit.
Limite de sens
Le terme ne dépasse pas la portée de test documentée.
Portée de testtest-scope
Ensemble précis des cas, données et comportements examinés par un test.
Invariants
- • Le nombre de tests et leur objet doivent être indiqués.
- • Un résultat de test doit être limité à son environnement et ses entrées.
À éviter
- • Une validation complète du produit.
- • Une preuve de déploiement.
Limite de sens
Une portée de test ne couvre pas les cas qui n’ont pas été exercés.
Sans collecte
Raisonner sur un scénario synthétique.
Le laboratoire reste dans le navigateur. Il ne demande ni secret, ni compte, ni donnée réelle et ne produit aucune attestation.