Cela s’adapte au flux de travail existant.
L’équipe déclare le contexte du système, décrit ses données avec des métadonnées Croissant et définit les contrôles pour traiter ses risques. Froga recueille les preuves des exécutions et des artefacts produits pour compléter la documentation technique.
Déclarations et observations
Déclaré par l’équipe
- finalité du système
- à quoi il sert et qui il affecte
- normes applicables
- celles que l’équipe déclare
- description des données
- métadonnées Croissant : origine, structure et conditions d’utilisation du jeu de données
La description consigne ce qui est déclaré ; elle ne vérifie pas les données à elle seule.
Recueilli lors de l’exécution
- Description du modèle
- Elle se complète à partir des composants, artefacts et résultats disponibles pour chaque exécution. Sa portée dépend des preuves recueillies.
L’équipe définit les contrôles
L’équipe décide comment traiter chaque risque : le réduire, l’accepter avec justification, l’éviter ou le transférer, et comment aborder les opportunités. Elle définit les contrôles nécessaires à chaque traitement.
Chaque contrôle précise ce qui est vérifié, selon quel critère et avec quelle preuve. Pour une vérification numérique, le critère d’acceptation comprend un seuil.
L’équipe définit séparément l’effet de chaque résultat sur la poursuite du travail.
Exemple fictif · chiffres simulés
RSK-DEMO
Des défauts qui échappent à l’inspection
- Impact déclaré
- Élevé
- Probabilité déclarée
- Possible
Enchaînement vers le dommage
Un type de pièce est peu représenté dans les données.
Le modèle détecte ses défauts avec moins de fiabilité.
La pièce poursuit le processus sans examen supplémentaire.
- Conséquence
- Une pièce défectueuse atteint l’assemblage et compromet la qualité du produit.
- Traitement du risque
- Réduire. Étendre la validation aux types de pièces et aux conditions de prise de vue ; examiner les cas incertains avant de publier la version.
Contrôles du traitement
Taux de détection des défauts. Chaque contrôle conserve son critère, son résultat et ses preuves.
C-01Détection globale
Critère satisfait
- Critère d’acceptation
- ≥ 95 %
- Résultat simulé
- 96 %
Preuve : Évaluation globale du jeu de données de test.
C-02Détection par type de pièce · groupe le moins performant
Critère non satisfait
- Critère d’acceptation
- ≥ 90 %
- Résultat simulé
- 82 %
Preuve : Évaluation ventilée par type de pièce.
C-03Détection sous éclairage défavorable
Non mesuré
- Critère d’acceptation
- ≥ 90 %
- Résultat simulé
- Non disponible
Preuve : Ces conditions restent à évaluer.
Échelle 0–100 %. Ligne pointillée : seuil. Repère plein : résultat simulé. Aucun repère : aucune mesure.
- Risque résiduel
- À réévaluer
- Décision configurée pour cet exemple
- Retenir la version jusqu’à résolution du contrôle en échec et réalisation de la mesure manquante.
Cas fictif d’inspection visuelle : les critères et résultats sont simulés, et ne sont ni des données client ni des seuils recommandés. Un contrôle satisfait ne démontre pas, à lui seul, que le risque est traité.
Les vérifications automatisées se distinguent des revues humaines documentées et des preuves qui ne permettent pas encore de conclure. Consigner une affirmation humaine ne la transforme pas en une vérification mesurée ou validée.
Où cela se branche
Froga s’intègre aux couches MLOps et DevSecOps de l’organisation pour réunir les preuves de la documentation technique, via les intégrations disponibles.
Dans l’organisation
MLOps
Versions des données, enregistrements d’exécution et métriques du modèle, selon les éléments fournis par chaque outil.
Dans l’organisation
DevSecOps
Code versionné et intégration continue, où Froga vérifie les livraisons selon les capacités de chaque connexion.
Résultat dans Froga
Documentation technique
Froga rassemble et signe les preuves, liées aux données, au modèle et aux contrôles documentés.
Avec quoi cela fonctionne
MLOps · données et exécutions
DVC
ancre le fichier de verrouillage ; un tiers le recalcule avec le dépôt
MLflow
ancre le digest des métriques ; il vit dans son propre magasin
Dagster
ancre sur son propre matériel ; il vit dans son propre magasin
DataLad
provenance dans l'historique, données par pointeur
DevSecOps · dépôts et intégration continue
GitHub
vérifie la livraison
GitLab
vérifie la livraison
Forgejo
client : ne vérifie pas la livraison
Ce qui reste signé
- commit
- registre des changements
- jeu de données
- traçabilité des données
- algorithme d’entraînement
- manifeste d’exécution
- métriques
- seuils mesurés
- modèle
- provenance signée
Ce qui est livré
La documentation technique produite est celle que l’équipe présente à l’organisme notifié. La couverture dit, norme par norme, ce qu’elle soutient et ce qu’elle ne soutient pas.
Et quand il n'y a pas de preuve pour affirmer ni pour nier, elle le dit. Elle ne le peint pas en vert.
Voir la couverture