Colonne ⑥ · Runtime Intelligence

Observer le réel et vérifier les effets

Elle lit l'état observé et les preuves, produit des signaux et rend un verdict sur l'outcome. Elle ne modifie jamais directement la production.

AIDO est un cadre, pas un outil. Cette page décrit ce que cette colonne doit garantir. Vous l'appliquez avec vos propres outils, vos seuils et vos règles.

Vous laissez l'IA agir sur vos opérations IT ? Cinq questions : le verdict, les signaux, qui vérifie, ce qu'elle peut faire quand le réel s'écarte de l'attendu, ce qu'elle n'est pas.

Lire le mécanisme ↓

LE RÉFLEXE DU SIGNAL VERT

Quand l'IA vient d'appliquer un changement, le réflexe est de croire ce qu'elle en dit, ou le premier signal vert : la commande a réussi, le service répond 200. Personne n'a comparé l'effet réel à ce qui était attendu, et un signal absent passe pour un zéro.

Runtime Intelligence remplace ce constat par un verdict calculé hors modèle, contre un contrat, où l'absence de preuve porte un nom : UNKNOWN.

Le mécanisme · le chemin d'un verdict · R14 · R12

Comment un changement reçoit-il son verdict ?

En cinq temps, toujours dans le même ordre. Le Verifier est indépendant du texte produit par l'Author (qui a préparé le changement) : il ne lit pas le compte rendu, il lit les signaux.

  1. 01 · CONTRAT

    L'outcome attendu, écrit avant le GO

    Le comportement observable visé, la baseline de comparaison, les seuils de succès et d'échec, la réponse prévue.

  2. 02 · SIGNAUX

    Ce qui est réellement mesuré

    Chaque signal requis, déclaré avec sa source, sa fraîcheur et son owner.

  3. 03 · COMPARAISON

    Calculée hors modèle

    Attendu, observé, statut, signal par signal. Le LLM peut expliquer les résultats ; il ne les calcule pas.

  4. 04 · VERDICT

    Une valeur sur quatre

    • pass
    • fail
    • unknown
    • degraded

  5. 05 · RÉPONSE

    Une décision sur cinq

    • promote
    • hold
    • rollback
    • degrade
    • escalate

CE QUE CHAQUE VERDICT DÉCLENCHE · VERIFY

  • PASS

    La promotion devient possible.

  • FAIL

    Déclenche la réponse prévue au contrat.

  • UNKNOWN

    Arrête la promotion. Ce n'est pas un échec : c'est une absence de preuve, et elle bloque.

  • DEGRADED

    Acceptable seulement si le contrat l'a prévu, avec une durée et un owner.

  • LE SILENCE N'EST PAS ZÉRO · R12Un signal stale, absent ou sans owner ne devient pas zéro : il devient UNKNOWN. C'est la ligne qui sépare un verdict d'un monitoring optimiste.
  • SANS ATTRIBUTION, PAS DE VERDICTSi le signal ne peut pas être attribué au changement, le verdict est UNKNOWN.
Voir l'enregistrement de vérification 
verification:
  trace_id: <id de la trace>
  contract_ref: <outcome contract déclaré avant le GO>
  baseline_ref: <preuve de l'état avant>
  candidate_ref: <empreinte de l'artefact candidat>
  started_at: <horodatage>
  ended_at: <horodatage>
  signal_results:
    - signal_id: <id du signal>
      expected: <seuil fixé par le contrat>
      observed: <valeur mesurée>
      status: <statut du signal>
  verdict: pass | fail | unknown | degraded
  response: promote | hold | rollback | degrade | escalate
  evidence_refs: [<références de preuve>]

Le framework fixe ces champs, pas leurs valeurs : chaque organisation fixe ses propres seuils.

Le mécanisme · les signaux · SENSE

Qu'est-ce qui compte comme un signal ?

Une mesure qui se déclare. Sans ces champs, on ne sait ni d'où vient une valeur, ni si elle vaut encore, ni qui en répond.

CE QU'UN SIGNAL DÉCLARE

  • idSon identifiant
  • typesli, business, security, cost, capacity, ai-quality, drift
  • sourceD'où vient la mesure
  • scopeCe qu'elle couvre
  • timestampQuand elle a été prise
  • SLO de fraîcheurJusqu'à quand elle vaut
  • unitéCe qu'on compte
  • agrégationComment on la calcule
  • ownerQui en répond
  • sensibilitéQui peut la lire
  • LE SLO PART DE L'USAGEAucun SLO n'est créé seulement parce qu'une métrique existe. Il part de l'expérience utilisateur ou de la fonction critique.
  • L'OUTCOME BORNE L'AUTONOMIEToute autonomie runtime est bornée par des outcomes. Un error budget peut bloquer ou réduire les changements.

CE QU'ELLE COMBINE · AUCUN VENDOR IMPOSÉ

  • métriques
  • logs structurés
  • traces distribuées
  • wide events quand nécessaire
  • probes synthétiques
  • monitoring métier
  • inventaire et drift
  • coût
  • capacité
  • sécurité
  • télémétrie de l'IA

La télémétrie de l'IA couvre modèle, retrieval, tool calls, latence, coût et outcome. Pas de « tout logger », et aucun objectif de SLO fixé par le cadre.

Le mécanisme · VERIFY · R14

Qui vérifie, et contre quoi ?

VERIFY est une étape runtime indépendante de l'Executor, celui qui a appliqué le changement. Elle compare le réel au contrat, sur ces contrôles :

  • INTÉGRITÉDe l'artefact et de la configuration.
  • SMOKE TECHNIQUELe service fonctionne au niveau technique.
  • SLI / SLO ET SIGNAUX MÉTIERCeux du contrat, pas seulement les techniques.
  • BASELINE / CANARYL'avant comparé au candidat.
  • DESIRED STATELa convergence vers l'état déclaré.
  • COÛT ET BLAST RADIUS RÉELSCe que le changement a coûté et touché.
  • VERDICTUn HTTP 200 seul ne prouve pas un outcome métier si d'autres signaux sont requis. Le verdict tient compte de tous les signaux du contrat.

PROGRESSIVE DELIVERY

  1. baseline
  2. candidate
  3. petite population
  4. bake time
  5. comparaison
  6. promotion

Chaque étape se compare à la baseline. Sans attribution suffisante du signal au changement, le verdict est UNKNOWN.

Le mécanisme · le runtime governor

Que peut-elle faire quand le réel s'écarte de l'attendu ?

Demander. Elle ne possède pas elle-même les credentials d'exécution : elle demande, le Control Plane exécute.

Elle peut demander

Les réponses à sa disposition

  • hold
  • freeze
  • canary plus petit
  • rollback
  • revoke
  • isolate
  • shed load
  • degrade
  • déclarer un incident

FinOps est une dimension de décision et de signal, pas une colonne séparée. Toute boucle qui peut créer des ressources porte budget, quotas, rate limit et kill switch.

Avant toute remédiation

Une anomalie n'est pas une cause

  • L'IA propose des hypothèses sourcées.
  • Elle cherche des preuves contradictoires.
  • La remédiation vient ensuite, jamais avant.
Voir un exemple : un changement promu par étapes, qui s'arrête sur UNKNOWN

Un seul changement, sans nom ni outil. Supposons que son contrat exige un signal technique et un signal métier.

  1. 1CONTRAT · R14Avant le GO, l'outcome attendu est écrit : signaux requis, baseline, seuils, réponse prévue.
  2. 2PROGRESSIVE DELIVERYLe candidat part sur une petite population, puis le bake time s'écoule avant la comparaison.
  3. 3SIGNAUXLe signal technique tient son seuil et le service répond 200. Le signal métier n'a pas d'owner.
  4. 4COMPARAISON · R12Calculée hors modèle, elle ne compte pas ce signal comme zéro : il devient UNKNOWN. Le 200 seul ne prouve pas l'outcome métier requis.
  5. 5VERDICTUNKNOWN : la promotion s'arrête. Le LLM peut expliquer ce résultat ; il ne l'a pas calculé.
  6. 6RÉPONSERuntime Intelligence peut demander un hold. Le Control Plane l'exécute : elle n'a pas les credentials.

Ce qu'elle produit

Que produit la colonne à chaque changement ?

01 · LES SIGNAUX

L'état réel, déclaré

Datés, sourcés, avec un owner et une fraîcheur. Périmés, absents ou orphelins, ils deviennent UNKNOWN.

02 · LES SLO

Les bornes de l'autonomie

Partis de l'expérience utilisateur ou de la fonction critique. L'error budget peut bloquer ou réduire les changements.

03 · LE VERDICT OUTCOME

Ce que le changement a réellement fait

Une valeur sur quatre, une réponse sur cinq, rattachées au contrat, à la baseline et à l'artefact candidat.

Dans la boucle

Où intervient-elle dans la boucle ?

Dans la boucle canonique, Runtime Intelligence tient les deux extrémités de l'action : SENSE et VERIFY.

SENSE
⑥
GROUND
④
DECIDE
①②
AUTHORIZE
②⑤
ACT
③
VERIFY
⑥
LEARN
⑦

⑥ en surbrillance · les autres badges mènent aux colonnes sœurs

SENSE

Lire l'état réel et produire les signaux, avant toute décision.

VERIFY

Comparer l'effet réel au contrat, hors modèle, et rendre le verdict.

Les règles qui la portent

  • R14OUTCOME CONTRACTL'outcome attendu est déclaré en contrat ; un HTTP 200 seul ne prouve pas un outcome métier si d'autres signaux sont requis.
  • R12FAIL-LOUDCe qui manque se dit : un signal stale, absent ou sans owner devient UNKNOWN, et UNKNOWN arrête la promotion.
  • R8RÉTROGRADATIONUn échec VERIFY rétrograde l'autonomie concernée.

L'inspection · test de complétude

Quel effet réel a été observé ?

Prenez un changement récent appliqué par l'IA sur un de vos systèmes réels. Pouvez-vous montrer, pièces à l'appui :

  1. 1le contrat d'outcome déclaré avant le GO, et la baseline de comparaison ;
  2. 2les signaux lus, avec leur source, leur fraîcheur et leur owner ;
  3. 3pour chaque signal, l'attendu, l'observé et le statut, calculés hors modèle ;
  4. 4le verdict rendu et la réponse qui a suivi ;
  5. 5que la vérification ne venait ni de l'Executor, ni du texte de l'Author.

Si vous ne pouvez pas répondre avec preuve, la colonne n'est pas encore en place. Ce n'est pas un jugement : une cartographie honnête est exactement le point de départ.

Le socle

Quelles fondations sert-elle ?

Les 8 fondations normatives et leur définition sont sur la page du temple.

Les limites font partie du contrat

Qu'est-ce que ce n'est pas ?

Elle dit ce qui a été observé, et refuse trois raccourcis.

  • Pas un exécutant. Elle demande hold, rollback ou isolate ; le Control Plane exécute.
  • Pas une prédiction. AIDO détecte plus tôt si les signaux et les tests existent ; il ne prédit pas par déclaration.
  • Pas un juge LLM. Le verdict est calculé hors modèle ; le modèle peut l'expliquer, pas le rendre.

La visite guidée

Voyons comment l'appliquer chez vous

30 minutes en visio, sur votre contexte : vos opérations, vos outils, la place de l'IA aujourd'hui, et ce que Runtime Intelligence y changerait.

Réserver un audit de 30 min

30 minutes · visio · créneau à choisir en ligne