A5 — IA : génération de structure de test depuis les Dossiers de conception / SFD

🆕 Évolution proposée — la plus ambitieuse de la section

Statut : 🟠 POC préalable obligatoire. Le fournisseur et l'architecture sont tranchés (voir §A5.3) ; la faisabilité qualitative ne l'est pas et ne peut l'être que sur documents réels.

En une phrase

Rédiger 400 flux de test à partir des dossiers de conception du client prend des semaines. La proposition : l'IA rédige un brouillon à partir d'un chapitre que vous avez choisi, et vous le validez — jamais l'inverse.

Trois choses à retenir avant d'entrer dans le détail.

1. Ce n'est pas « je dépose le document, l'outil fait le plan de test ». Aucun éditeur du marché ne le propose, parce que ça ne fonctionne pas. Le geste utile est : vous désignez un chapitre et l'endroit où le rattacher, l'IA propose, vous validez.
2. Rien n'est écrit dans l'outil sans validation humaine. L'écran de revue est le cœur du dispositif, pas une formalité.
3. Le coût n'est pas un sujet : de l'ordre de 20 centimes par flux généré, quelques dizaines d'euros par mois. Le vrai sujet est la confidentialité des documents du client — voir §A5.3.

A5.1 Ce que fait réellement le marché

Ce constat calibre notre ambition — il ne s'agit pas de faire moins bien, mais de ne pas promettre ce que personne ne livre.

• Xray — on sélectionne une ou plusieurs exigences / issues, l'IA propose des titres et descriptions, l'utilisateur revoit, édite ou rejette, puis les tests (manuels ou Cucumber) sont créés.
• TestRail 9.5 — on choisit une section et un modèle, on saisit l'exigence en texte, l'IA propose titres et descriptions ; l'utilisateur peut corriger, réorienter ou exclure avant génération complète. Le human-in-the-loop est revendiqué comme le cœur du dispositif.
• Zephyr / HaloAI — lecture de la story Jira liée → cas de test brouillon avec étapes, jeu de données et résultats attendus.

➡️ Constat structurant : l'entrée est toujours une exigence textuelle courte et sélectionnée, jamais un document de 80 pages ingéré d'un bloc. Une approche « je dépose le Dossier de conception, l'outil génère le plan de test » ne correspond à aucune offre du marché et n'est pas un objectif réaliste en première itération.

Contrepartie positive : l'IA est le différenciateur 2026 du secteur et il est inégalement couvert — Qase (AIDEN), PractiTest (SmartFox) et qTest (Copilot) la facturent au crédit, Zephyr Scale en a peu, celle de TestRail reste limitée. Bien exécuté, A5 est un axe de différenciation réel.

A5.2 Pipeline proposé — 4 étapes, l'humain aux étapes 2 et 4

1. Ingestion — dépôt du Dossier de conception ou de la Spécification Fonctionnelle (PDF, DOCX). Le document est découpé par chapitres, chaque morceau conservant sa provenance (fichier, version, section, page).
2. Cadrage humain — l'utilisateur choisit le ou les chapitres pertinents (un processus, une section) et l'endroit du plan de test où les rattacher (module → fonctionnalité → scénario). Pas de bouton « générer tout le document ».
3. Génération — l'IA propose un flux et ses étapes (intitulé, description, jeu de données, résultat attendu), plus une suggestion de rattachement CRIM si un code est détecté dans le texte. La proposition est contrainte au même format que la saisie manuelle : elle ne peut pas sortir des rails.
4. Revue obligatoire — écran de validation : accepter / éditer / écarter / régénérer. Rien n'est enregistré sans validation humaine. Chaque flux créé garde la trace de son origine (fichier, section, pages, date) pour l'audit.

Précisions d'implémentation par étape : (1) stockage dans Convex File Storage, fragments persistés avec leur provenance ; (3) appel au modèle avec un schéma de sortie contraint, le JSON produit étant validé par le même schéma Zod que la création manuelle (@recette/validators) ; (4) champ generatedFrom (fichier, section, pages, version du modèle, date) sur chaque flux créé.

A5.3 Décisions techniques tranchées

Le self-hébergement est écarté — et c'est chiffré

Élément	Valeur
Notre consommation projetée	1 à 10 millions de tokens par mois, en pointe
Seuil de rentabilité du self-hosting (littérature 2026)	5 à 10 M tokens / mois pour un modèle haut de gamme ; franchement favorable seulement au-delà de 50 à 100 M tokens / jour
Coût réel du self-hosting	le GPU brut ne représente que 30 à 40 % du coût ; TCO total ×3 à ×5 par rapport au chiffre du tableur
Charge d'ingénierie	20 à 30 % du temps d'un ingénieur senior (~3 000 à 6 000 $/mois) en maintenance continue
Profil de charge	irrégulier (journée ouvrée, zéro la nuit et le week-end) → 60 à 70 % de temps GPU payé inutilisé

➡️ À notre volumétrie, le self-hébergement coûte un à deux ordres de grandeur plus cher que l'API, pour une qualité au mieux équivalente. Il ne se justifierait que par une contrainte contractuelle de non-sortie des données, jamais par le coût. Sujet clos.

Coût par API — le budget n'est pas un facteur de décision

Tarifs publics Claude (par million de tokens, juillet 2026) :

Modèle	Entrée	Sortie	Contexte
Claude Opus 4.8	5 $	25 $	1 M
Claude Sonnet 5	3 $	15 $	1 M
Claude Haiku 4.5	1 $	5 $	200 K

Une génération (≈ 15 000 tokens en entrée — un fragment sélectionné, pas le document entier — et 8 000 en sortie) coûte ≈ 0,17 $ en Sonnet 5, ≈ 0,28 $ en Opus 4.8. Deux cents générations par mois ≈ 35 à 55 $.

Trois leviers réduisent encore ce chiffre : mise en cache du prompt (lectures facturées ~0,1× le tarif d'entrée — si le même document sert de préfixe à plusieurs générations, l'entrée est quasi gratuite dès la deuxième), API Batch (−50 % si la génération peut être asynchrone, ce que l'écran de revue permet), et modèle dégradé pour les tâches simples (extraction de codes CRIM → Haiku).

Fournisseur retenu : API Claude directe + clause ZDR

✅ Décision du 20/07/2026

Scénario retenu : API Claude directe, avec clause de Zero Data Retention négociée.

#	Scénario	Résidence des données	Statut
S1	API Claude directe + ZDR	US	✅ retenu
S2	Claude via AWS Bedrock Francfort ou Vertex AI UE	UE	🔁 repli contractuel si le client exige la résidence UE
S3	Mistral Enterprise (SecNumCloud / OVHcloud, hors CLOUD Act)	France	🔁 repli si exigence de souveraineté stricte

Ce qu'il faut savoir sur S1 :

• Les données de l'API ne sont pas utilisées pour entraîner les modèles (politique par défaut).
• Le Zero Data Retention est disponible sur demande commerciale, après approbation, et s'active par organisation : ni prompts ni réponses conservés après renvoi de la réponse. À obtenir avant la mise en production, pas après.
• ⚠️ Limite assumée : le paramètre inference_geo de l'API directe n'accepte que us et global — il n'existe pas d'option UE dédiée sur l'API directe. La résidence UE passe obligatoirement par AWS Bedrock (Francfort) ou Vertex AI (régions UE), où des profils d'inférence maintiennent le traitement dans les régions configurées.
• ⚠️ En S2, on perd l'API Batch (−50 %), la Files API et la recherche web ; le client SDK change (AnthropicBedrockMantle). Le CLOUD Act reste applicable — seul S3 y échappe.

🔒 Règle d'architecture qui rend le repli peu coûteux : ne jamais coder en dur le client du fournisseur dans les fonctions métier. Une seule couche d'accès au modèle, injectable. À cette condition, la bascule S1 → S2 est une journée de travail, pas une refonte.

Trois capacités qui changent ce qu'on peut promettre

1. Les PDF sont lus tels quels, mise en page comprise (tableaux, schémas). Pas d'étape de reconnaissance de caractères, donc pas de perte de qualité — à condition que les documents soient des PDF « vrais » et non des scans, ce qui est confirmé côté client.
2. La sortie est contrainte au format attendu, elle n'est pas « demandée poliment ». Un flux généré a exactement la même forme qu'un flux saisi à la main — mêmes champs, mêmes règles de validation.
3. Chaque étape générée peut citer sa page d'origine. On ne dit plus « généré depuis le DCF v2 » mais « généré depuis le DCF v2, pages 34 à 36 ». C'est directement exploitable en audit de recette : on justifie chaque test par le passage du dossier de conception qui le motive.

Capacité	Ce que ça change pour A5
Lecture native des PDF	Un PDF part tel quel (≤ 32 Mo, ≤ 600 pages), sans OCR ni pipeline d'extraction maison. Le DOCX est converti côté serveur. ✅ Confirmé applicable : PDF/DOCX natifs à texte sélectionnable (Q25 tranchée).
Sorties structurées (output_config.format + JSON Schema)	La sortie est contrainte au schéma. Le JSON Schema se dérive du Zod de @recette/validators → une seule source de vérité pour la création manuelle et la génération IA.
Citations (citations: enabled)	Chaque bloc généré porte sa page source (page_location). ⚠️ Les citations sont incompatibles avec les sorties structurées dans la même requête (erreur 400) → deux passes, ou renoncer à l'une. À arbitrer à l'implémentation.
Files API	Un document uploadé une fois est réutilisable par file_id : évite de re-téléverser un DCF de 20 Mo à chaque fragment généré.

Où le code s'exécute — contraintes Convex

Contrainte	Conséquence
Query / mutation : 1 s de code utilisateur	L'appel modèle ne peut pas vivre dans une mutation → action
Action runtime Node : 10 min (runtime Convex : 30 min)	Largement suffisant pour une génération
Argument d'une action Node : 5 Mio	⚠️ Un DCF de 20 Mo ne passe pas en argument → dépôt préalable dans Convex File Storage, l'action lit le stockage
Écriture	La validation humaine (étape 4) déclenche une mutation classique — les flux générés entrent par le même chemin que la création manuelle

Le composant action-retrier couvre la reprise sur échec réseau ; le scheduler Convex couvre le mode asynchrone (dépôt → notification quand la proposition est prête).

A5.4 Droits

Génération : admin + consultant. Un testeur ne crée pas de référentiel. La revue (étape 4) suit les mêmes droits que la création manuelle de flux.

A5.5 Livrable préalable — le POC, et son critère chiffré

Aucune spécification détaillée ne sera écrite avant ce POC.

Élément	Valeur
Matériau	1 Dossier de conception + 1 SFD réels du client
Critère d'acceptation	≥ 60 % des étapes générées conservées sans réécriture
Mesure secondaire	temps de revue humaine par flux généré vs temps de rédaction manuelle
Décision	sous le seuil → A5 est réduit à une aide à la rédaction (suggestion de titres) ou reporté

Sans ce chiffre, le sujet ne peut pas être arbitré — ni techniquement, ni commercialement.

A5.6 À trancher — Q20 (Q25 tranchée — voir Décisions actées)

Question	État
Self-host vs API	✅ tranché — API (§A5.3)
Fournisseur	✅ tranché — S1 (API Claude directe + ZDR), replis S2/S3 documentés
Format des documents	✅ tranché — PDF/DOCX natifs, texte sélectionnable → lecture native applicable
Clause ZDR effectivement obtenue ?	🔴 à obtenir avant production
Le client exige-t-il par écrit la résidence UE / la non-soumission au CLOUD Act ?	🔴 bloquant — déclenche le repli S2 ou S3
Les DCF/SFD contiennent-ils des données à caractère personnel ou sous NDA renforcé ?	🔴 bloquant — change la nature de l'engagement contractuel
Volumétrie réelle (nombre de documents, de générations attendues)	🟠 à confirmer — conditionne le chiffrage
Qui a le droit de générer	🟢 proposé : admin + consultant