Pourquoi ce sujet est important
Un week-end suffit pour tester une hypothèse, pas pour bâtir une plateforme complète. Le bon MVP réduit le risque principal : le modèle peut-il produire un résultat utile sur des cas réels, avec un coût et un délai acceptables ?
Vendredi — cadrer le test
Écrivez une phrase : pour quel utilisateur, quelle entrée, quel résultat et quelle action suivante ? Définissez cinq cas fréquents, cinq difficiles et deux échecs acceptables. Mesurez la baseline humaine ou logicielle. Écartez les fonctionnalités annexes, l’authentification complexe et le multi-agent.
Choisir une architecture minimale
Commencez par un appel serveur, une sortie structurée et une interface simple. Ajoutez un RAG seulement si la réponse dépend de documents externes. Utilisez un service managé pour la base ou le modèle afin de concentrer le week-end sur la valeur. Gardez la clé côté serveur.
Samedi matin — préparer les données
Sélectionnez un petit corpus autorisé et représentatif. Nettoyez les exemples, retirez secrets et PII, puis créez un jeu d’évaluation séparé. Pour un RAG, conservez provenance, titres et pages. N’ingérez pas toute l’entreprise.
Samedi après-midi — construire le flux
Implémentez validation d’entrée, appel au modèle, validation de sortie, affichage des sources et gestion des erreurs. Ajoutez timeout, budget et journalisation minimale. Le prototype doit échouer proprement plutôt que masquer une réponse inventée.
Dimanche matin — évaluer
Rejouez les cas sans les modifier pour favoriser le modèle. Notez exactitude, erreurs graves, latence et coût. Comparez à la baseline. Faites tester par une personne qui n’a pas construit le prototype. Analysez les échecs par catégorie.
Dimanche après-midi — démontrer et décider
La démo doit montrer un cas réussi, un cas limite et un refus. Présentez mesures, données utilisées, risques et prochaine expérience. Décidez : arrêter, approfondir, changer d’approche ou lancer un pilote contrôlé.
Ce qui vient après
Un MVP positif doit encore recevoir sécurité, observabilité, tests, gestion des droits, conformité et exploitation. Transformez les exemples en tests de régression et lancez avec un petit groupe via feature flag.
Exemple concret
Une équipe teste la synthèse de tickets support. Elle utilise 60 tickets anonymisés, dont 20 pour l’évaluation. L’application produit résumé, produit et urgence en JSON. Après le week-end, le résumé est utile mais l’urgence instable : le pilote conserve cette décision humaine.
Les erreurs fréquentes
- essayer plusieurs agents et bases dès le départ
- construire une interface avant le test métier
- utiliser uniquement des exemples faciles
- envoyer des données sensibles à un compte personnel
- ne pas mesurer coût et latence
- présenter une démo comme un produit fini
Checklist
- [ ] Hypothèse testable écrite
- [ ] Baseline et seuil définis
- [ ] Données autorisées et minimisées
- [ ] Architecture minimale
- [ ] Sortie validée
- [ ] Jeu d’évaluation séparé
- [ ] Échecs montrés dans la démo
- [ ] Décision et prochaine étape documentées
FAQ
Quelle stack choisir ?
Celle que l’équipe maîtrise, avec un SDK serveur, une interface simple et des services managés réversibles.
Faut-il un RAG ?
Seulement si les réponses reposent sur des documents que le modèle ne connaît pas ou doit citer.
Combien d’exemples ?
Quelques dizaines bien choisis suffisent pour apprendre, mais pas pour prouver la production.
Que doit produire le week-end ?
Une mesure et une décision, pas seulement une démonstration séduisante.