Démarche Qualité IA Act.

Ce site est exploité par Ailiance software comme vitrine publique d'une infrastructure LLM européenne. Il relève du règlement (UE) 2024/1689. Les six blocs ci-dessous décrivent notre démarche qualité : documentation technique, information intégrateurs, résumé des données, procédure de validation, vérification des biais, et mécanisme d'incidents. L'obligation d'information d'utilisation IA (Article 50) apparaît dès l'accueil.

1 · Documentation technique actualisée par modèle

Chaque modèle servi expose un fichier JSON de provenance Annex IV §1(c) couvrant son entraînement, ses tests et ses résultats — publié dans ailiance/ailiance/docs/provenance/, daté et signé par commit Git.

• Entraînement — repository source, SHA upstream, méthode (LoRA bf16 MLX, distillation, quantization), hyperparamètres, durée et coût matériel
• Tests — suites Lighteval / EvalPlus / MT-Bench / iact-bench avec git_sha et methodology pinned
• Résultats — scores par domaine, perplexité, task-score, LLM-judge, et validator exit-codes — toutes les cellules rejouables byte-à-byte

2 · Information pour intégrateurs — capacités et limites

Chaque model card HuggingFace déclare explicitement les capacités prévues et les limites — conformément à l'Article 53 pour les fournisseurs de modèles GPAI.

• Capacités — domaines de spécialisation (KiCad, ngspice, embarqué, droit FR, médical EU, math), langue(s) supportées, longueur de contexte maximale, modes (chat, code, raisonnement)
• Limites — cas hors-périmètre, modes connus de défaillance (hallucination de pin-out, confusion d'unités, biais culturels), seuils de confiance recommandés
• Pré-requis matériels — quantization disponible, mémoire minimale, débit attendu sur backend de référence
• Intégration — endpoint OpenAI-compatible /v1/chat/completions, exemples d'appel curl/Python, paramètres recommandés par cas d'usage

3 · Résumé compréhensible du contenu utilisé en entraînement

Pour chaque adaptateur publié, nous fournissons un résumé en français accessible (pas uniquement un dump technique) :

• Sources principales — corpus internes Ailiance software (distillation synthétique de traces Claude Opus, documentation technique publique, prompts curés manuellement) et jeux de données ouverts sous licence (Stack Exchange, KiCad upstream, Wikipédia, Common Crawl filtré)
• Volume et composition — nombre approximatif d'exemples, distribution par langue, distribution par domaine
• Exclusions — contenus protégés non utilisés sciemment, respect des signaux d'opt-out (robots.txt, ai.txt) pour les données web
• Période de collecte — bornes temporelles des sources

4 · Procédure documentée de conception et de validation

La méthodologie iact-bench v1 est versionnée et exécutable. Chaque release d'un modèle suit une procédure formelle reproductible :

• Conception — sélection du modèle base, justification de la méthode (LoRA vs full fine-tune vs distillation), choix des hyperparamètres documenté dans le fichier de provenance
• Validation pré-publication — iact-bench complet (31 domaines × ≤23 modèles) + ~46 validators sur 3 backends : sandbox Docker (g++, KiCad DRC/ERC, ngspice, shellcheck, tsc, etc.), kicad-mcp-pro et KiKit, avec digests sha256 épinglés
• Jury LLM — le score LLM-judge d'iact-bench est calculé par Qwen3-Coder-30B et EuroLLM-22B. Mistral-Small-3.1 est tenu à l'écart de l'usage texte/jury en raison d'un bug connu du détokeniseur omlx (remonté en amont, contourné en aval).
• Critères de release — gain mesurable sur le domaine cible vs base model, absence de régression critique sur les autres domaines, validator exit-zero sur ≥ 80% des cellules domain-critical
• Trace d'audit — NDJSON par run avec run_id, git_sha, seed, validator_image_digest, prompt_hash et output_hash

5 · Processus de vérification des données d'entraînement

Trois axes contrôlés systématiquement avant fine-tuning :

• Qualité — dédup near-duplicate (MinHash), filtrage des artefacts (HTML résiduel, encodage cassé, tronqué), validation syntaxique pour les corpus code/JSON/YAML, score de cohérence sur échantillon stratifié
• Biais — audit sur axes protégés (genre, origine, opinion politique, religion) via classifiers ouverts, comparaison de la distribution corpus vs distribution attendue, alerte si écart-type > 2σ
• Représentativité — couverture des sous-domaines techniques (par exemple en KiCad : symboles vs footprints vs schémas vs PCB layout), équilibrage langue FR / EN, équilibrage difficulté (basique → expert)

Les scripts de construction et d'audit des corpus sont publiés dans ailiance/scripts/ (par exemple augment_router_data.py, build_hf_datasets.py, calibrate_threshold.py, fix_provenance.py) et exécutés en CI à chaque mise à jour de corpus.

6 · Mécanisme de remontée et de traitement des incidents

Un canal unique de remontée pour plaintes, erreurs, biais détectés ou préoccupations de droit d'auteur : [email protected].

• Réception — accusé sous 48 heures ouvrées, identifiant d'incident unique, qualification (plainte / erreur factuelle / biais / droit d'auteur / autre)
• Investigation — reproduction de la sortie incriminée si possible (NDJSON audit-grade contient prompt_hash + seed), analyse de la chaîne de provenance, identification du ou des modèles concernés
• Traitement — retrait temporaire du modèle si gravité élevée, patch dataset ou règle de routage si biais reproductible, ré-entraînement si nécessaire, mise à jour de la model card
• Communication — réponse documentée au plaignant sous 7 jours ouvrés, et publication d'un post-mortem anonymisé dans docs/incidents/ si l'incident a entraîné un changement de modèle ou de politique
• Registre public — incidents par catégorie et délais de traitement publiés trimestriellement sur cette page