Avant le développement
Fiabiliser une spécification
Repérer les trous, les ambiguïtés et les critères manquants avant qu'ils ne coûtent en recette.
À vous, sur votre projet
Une revue structurée de la spécification et la liste précise des éléments à compléter avant le développement.
Le métier décide comment lever chaque ambiguïté. Vous validez la version qui peut entrer en build.
Voir un exemple interactif
Parcourez les documents fictifs, le travail des agents et le support à personnaliser. Aucun document à déposer et aucune analyse IA exécutée dans cet exemple.
Préparer vos documents et choisir les agents
Une spécification doit partir en développement, mais certaines règles, certains cas limites ou critères d'acceptation restent implicites.
La question à préparer
Que faut-il clarifier avant le build pour éviter les interprétations, les retours et les reprises tardives ?
Vos éléments en entrée
Spécification, user stories, règles métier, critères d'acceptation et notes d'atelier.
Ce que font les agents
Le Limier relit la spécification, signale les trous et formule les questions à trancher sans inventer les réponses. Le Scribe peut ensuite transformer l'atelier de clarification en décisions et actions traçables.
Le livrable obtenu
Une revue structurée de la spécification et la liste précise des éléments à compléter avant le développement.
Ce que vous obtenez — la revue : voir un exemple détaillé
Exemple réel du fil rouge Helios (projet fictif, portail bancaire, cycle en V) : à gauche trois exigences telles qu'écrites, à droite la revue produite par Le Limier — ambiguïtés, trous et critères manquants, chacun renvoyé à son exigence.
Ce que vous collez — la spécification
EXIGENCE 3.2 — Réinitialisation du mot de passe « Le client doit pouvoir réinitialiser son mot de passe rapidement et de façon sécurisée. » EXIGENCE 3.5 — Historique des opérations « L'utilisateur consulte l'historique de ses opérations. » EXIGENCE 4.1 — Performance « Le portail doit être rapide, même en forte charge. »
Ce que vous obtenez — la revue
1. SYNTHÈSE DE MATURITÉ
critères restant à démontrer avant le build — ambiguïtés critiques sur la performance et la sécurité.
2. AMBIGUÏTÉS
- « rapidement » (3.2) et « rapide / forte charge » (4.1) : non chiffrés.
3. TROUS
- Gestion d'erreur de la réinitialisation MDP : absente des documents fournis.
- Durée de conservation de l'historique (3.5) : non spécifiée.
- Critères d'acceptation : absents sur les 3 exigences.
4. CRITÈRES À FAIRE VALIDER
- Perf : quelle valeur cible, quelle charge et quel percentile doivent être observables ?
5. QUESTIONS PRIORITAIRES
définir le SLA de perf ; la politique de réinitialisation ; la rétention de l'historique.
Points de méthode
- Chaque ambiguïté est renvoyée à l'exigence précise qui la porte.
- Un critère d'acceptation manquant est signalé, pas comblé au hasard.
- Les critères proposés sont marqués « à valider » — c'est le métier qui tranche.
Ce qui reste à vérifier
- Le Limier signale ce qui manque. Il n'invente pas la règle métier à votre place.
- Ce qui n'est pas dans la spec est marqué absent, pas supposé.
- Le fichier original est supprimé après lecture. Seul le texte envoyé à l’agent est conservé dans votre espace. Aucun entraînement d’IA.