Software Crew AI Logo

Software Crew AI

Du flou à la User Story en un dialogue

L'IA qui structure vos besoins en spécifications prêtes à être développées

Elodie TURLIER
ALYRA - Session Douglas-Adams - Décembre 2025
Certification RS5487 - Maîtrise thématique

Le Problème Terrain

Contexte Big Data : explosion du volume et de la variété des données projet → besoin d'IA

"Lundi matin, sprint planning.
Le PO présente un ticket : 'Ajouter l'authentification sur l'application'.
Un des dev demande : 'OAuth ? JWT ? Session ? SSO ? Gestion des rôles ?'
Silence. Le ticket repartira en backlog."
25 milliards d’heures/an perdues à cause d’une collaboration inefficace.
69 % des développeurs perdent au moins 8 h/semaine à reformuler ou interpréter les specs.
47 % des professionnels jugent la rédaction de spécifications comme l’étape la plus frustrante.
50 % du coût d’un projet peut être absorbé par du rework lié à des besoins mal définis.
lightbulb Le cadrage flou coûte cher en temps, en qualité et crée des frictions au sein de l'équipe.

Software Crew AI - La Solution

Besoin flou
(texte, doc)
→
Dialogue IA
(clarifications)
→
User Story structurée
(INVEST + Gherkin)
timer
Cadrage guidé
Questions ciblées
handshake
Médiateur
Produit ↔ Tech
menu_book
RAG
Contexte projet
check_circle
Standards
INVEST, Gherkin
lightbulb Un dialogue structuré remplace des heures de réunions

Analyse des Parties Prenantes

Comprendre les utilisateurs pour concevoir la bonne solution

Persona Problème actuel Valeur apportée Adoption
Product Owner Temps de cadrage long, reformulations multiples User Stories structurées rapidement Utilisateur principal
Développeur Specs floues, questions récurrentes Critères d'acceptation clairs Bénéficiaire indirect
Scrum Master Sprints perturbés par le rework Vélocité stabilisée Sponsor potentiel
Client / Métier Incompréhension du livrable final Validation en amont À convaincre

check_circle Quick wins

  • PO : gain de temps immédiat
  • Dev : moins d'allers-retours

warning Points d'attention

  • Ne pas by-passer la validation métier
  • Former les PO à l'outil
lightbulb Un outil n'a de valeur que s'il répond aux vrais problèmes des utilisateurs

Stratégie de Validation

Méthode déductive : Hypothèses → Expérimentation → Validation

Hypothèse A

NLP & Fine-tuning
Flan-T5
POC non terminé
VS

Hypothèse B

Prompt Engineering
+ RAG
check POC validé
lightbulb Deux approches testées = décision éclairée

Hypothèse A - Approche & Données

Stack technique

Frontend Streamlit (Python)
Backend FastAPI
Data Pandas, HuggingFace Datasets
Modèles Flan-T5-base (extraction tags) + Flan-T5-small (fine-tuning)
Training PEFT, Trainer, TrainingArguments (HuggingFace)

data_object Phase 1 : Extraction

  • Export Jira → Pandas DataFrame
  • Nettoyage & anonymisation
  • Flan-T5-base → extraction tags
  • Split train/test

model_training Phase 2 : Fine-tuning

  • Tokenization des descriptions
  • Fine-tuning T5-small avec PEFT
  • DataCollatorForSeq2Seq
  • Trainer HuggingFace

output Phase 3 : Inférence

  • Input utilisateur → tags
  • Tags + modèle fine-tuné
  • Génération User Story
  • Affichage Streamlit
lightbulb Pipeline complet NLP : de la donnée brute Jira à la génération de User Stories

Hypothèse A - Bilan & Apprentissages

Pourquoi non abouti ?

  • Dataset Jira hétérogène → effort de data curation sous-estimé
  • Courbe d'apprentissage sous-estimée (Python, NLP, Transformers, PEFT)
  • Fine-tuning T5 : complexité technique vs temps disponible
  • Génération de texte ≠ classification : paradigme différent
  • Leçon : ne pas s'obstiner sur une solution imaginée sans maîtriser toutes les briques

Compétences acquises

  • Python : concepts, logique, écosystème IA
  • Data pipeline : Pandas, nettoyage, transformation
  • HuggingFace : Datasets, Tokenizers, Trainer, PEFT
  • Architecture : FastAPI, Streamlit, Docker
  • Stratégie IA : arbitrage fine-tuning vs prompt engineering
workspace_premium
Validation certification RNCP
Compétences NLP, préparation de données, pipeline d'entraînement de modèles
Code source GitHub
lightbulb Un POC "non abouti" reste un apprentissage précieux - il a orienté vers la bonne solution

Hypothèse B - Prompt Engineering + RAG

Approche

  • LLM généraliste + prompts optimisés
  • Agent conversationnel (pattern ReAct)
  • Enrichissement contextuel (RAG)

Pourquoi ça marche

Cold-start Zero-shot, pas de dataset
Flexibilité Modifier prompt en quelques min
Maintenabilité Dev standard suffit
Scalabilité 1 modèle + X contextes
lightbulb Prompt engineering = itération rapide sans ML Engineer

Stack & Architecture

Stack

Frontend Angular 21 + SSE
Backend FastAPI Python
LLM Architecture multi-provider avec un modèle unique : Mistral 7B
- API Cloud Mistral (Prod)
- HuggingFace Transformers (Prod confidentialité)
- Ollama (Dev Local)
Vector DB Qdrant
Agent LangGraph (pattern ReAct)
Observabilité Langfuse (tracing LLM)

Architecture Agent

Message
→
Analyze
→
Tools
→
Output

5 outils :
- ask_user
- search_rag
- parse_file
- generate_us
- stop
Garde-fous : 3 itérations max, timeout 5min

lightbulb Stack état de l'art + Agent contrôlé = itération maîtrisée

Choix du Modèle - Démarche Consultant

Analyse des besoins → Recommandation argumentée

Grille de décision

Critère projet Besoin identifié Mistral 7B
Langue Français natif (User Stories en français) check Modèle français
Licence Déploiement libre, pas de vendor lock-in check Apache 2.0
Confidentialité Option on-premise pour clients sensibles check Ollama / HuggingFace
Budget POC à coût maîtrisé check Open source
Infrastructure Hardware standard, pas de GPU dédié check 7B = ~8GB RAM

Alternatives écartées

  • GPT-4 / Claude - Coût élevé, données hors UE
  • Llama 70B - Trop lourd pour POC
  • GPT-3.5 - Moins bon en français

Flexibilité conservée

  • Multi-provider - Changement facile
  • Abstraction LLM - Code découplé
  • Évolutif - Mistral Large si besoin
lightbulb Choix pragmatique aligné sur les contraintes projet - pas le "meilleur" modèle, le plus adapté

RAG - Contextualisation Dynamique

Retrieval-Augmented Generation : enrichir le LLM avec le contexte projet

Comparaison Sans RAG vs Avec RAG

warning Sans RAG

  • Ignore le vocabulaire métier du projet
  • Pas de contexte sur les specs existantes
  • Réponses génériques, déconnectées

check_circle Avec RAG

  • Accès aux docs projet (specs, README)
  • Réponses ancrées dans le contexte réel
  • Sources citées = traçabilité
update
Mise à jour facile
Sans réentraînement
visibility
Transparence
Sources vérifiables
rocket_launch
Cold-start
Dès le 1er document
savings
Coût maîtrisé
Embeddings peu coûteux
lightbulb RAG = donner au LLM la mémoire du projet, pas juste des connaissances générales

Pipeline RAG - Implémentation

La qualité du RAG dépend de la qualité du corpus

Pipeline RAG - Indexation et Retrieval

assignment Stratégie Corpus

  • Signifiance - Docs projet (specs, README)
  • Exploitabilité - Chunking adapté, métadonnées
  • Qualité - Sources traçables

settings Configuration

Embedding BGE-M3 (1024 dim)
Chunking 500 tokens, overlap 50
Vector DB Qdrant
Retrieval Top-5, score > 0.5
lightbulb RAG n'est pas magique : garbage in, garbage out

Cadre Juridique & Éthique

Réflexion menée en amont du développement

IA Act (applicable août 2026)

  • Classification : Risque minimal
  • Pas de décision automatisée critique
  • Pas de données biométriques
  • Pas de scoring social
  • Validation humaine obligatoire

RGPD

  • Base légale : Intérêt légitime
  • Rétention : Session uniquement
  • Option : Déploiement local (Ollama)
  • Données restent dans l'UE (Mistral API)

Principes éthiques appliqués (GEHN IA)

person
Contrôle humain
visibility
Transparence
security
Robustesse
history
Traçabilité
lightbulb Conformité by design - l'éthique intégrée dès la conception

Risques Identifiés

Ce qui est en place vs ce qui reste à faire

check_circle Implémenté

  • Température 0.3 - limite la créativité/invention
  • Multi-provider - choix Mistral API / Ollama / HuggingFace
  • Few-shot - exemples de bonnes User Story + template
  • Validation humaine - la User Story générée doit être relue

warning À implémenter

  • Citation des sources RAG - traçabilité à ajouter
  • Fallback automatique - si un provider tombe
  • Gestion des coûts API - monitoring pour production

Contraintes observées

speed
Latence variable
selon provider
payments
Coût API
à budgéter
data_array
Limite contexte
taille tokens
lightbulb POC = identifier les risques - MVP = les adresser

Démonstration

Voir sur Loom ↗

0:00 - 0:36 Cas 1 - Sans contexte
0:25 - 1:26       Aller/Retour sur des questions de clarification
1:26 - 2:08       Génération de 5 user stories (INVEST)
2:08 - 3:00 Cas 2 - Ajout d'un contexte projet
3:00 - 3:37       Question utilisateur sur le projet → Recherche RAG → Sources trouvées → Réponse contextualisée
3:37 - 5:00       Ajouter nouvelle fonctionnalité → Questions de clarification → Génération User Story contextualisées

Bilan & Retour d'Expérience

Décision

Prompt Engineering + RAG check
  • Approche validée par le POC
  • Itération rapide sans ML Engineer
  • Flexible et maintenable

Honnêteté sur le livrable

  • POC d'expérimentation, pas un MVP
  • Montée en compétences Python en parallèle
  • Démarche exploratoire et itérative
  • Architecture à consolider

Pour aller vers un vrai MVP

code
Refactoring
& Tests
cloud_upload
Déploiement
security
Sécurité
groups
Tests utilisateurs
lightbulb POC réussi - l'approche est validée, le chemin vers le MVP est tracé

Conduite du Changement

Anticiper les résistances, accompagner l'adoption

Résistances anticipées

Crainte Réponse
"L'IA va remplacer le PO" L'IA assiste, le PO valide et décide
"On perd le contact métier" L'outil structure l'échange, ne le remplace pas
"C'est une boîte noire" Sources RAG traçables, transparence

Stratégie d'adoption progressive

Un utilisateur final sera consulté tout au long de la création du produit afin de valider son utilité et son adaptation au plus proche du terrain.
science
Phase 1
1 projet pilote
1 PO volontaire
arrow_forward
feedback
Phase 2
Retours & ajustements
Quick wins visibles
arrow_forward
groups
Phase 3
Généralisation
Formation équipes
lightbulb L'adoption d'un outil IA se gagne par la confiance, pas par l'imposition

Conclusion

La promesse de Software Crew AI

"Améliorer la performance"
besoin flou
→
User Story complète
prête à développer

Questions ouvertes

  • Comment adapter à d'autres contextes métier ?
  • Quel équilibre automatisation / contrôle humain ?
  • Comment mesurer la valeur générée ?

Merci - Questions ?

Glossaire

Définitions des termes clés

Glossaire (1/4)

Agent

Un système autonome qui utilise un LLM comme "cerveau" pour planifier, raisonner et exécuter des actions. L'agent peut utiliser des outils externes (recherche web, calculatrice, APIs, code...), prendre des décisions et itérer jusqu'à atteindre un objectif donné.

Chunking

Processus de découpage d'un document en morceaux plus petits (chunks). Essentiel pour le RAG car les modèles ont une limite de contexte et les embeddings sont plus efficaces sur des segments de taille raisonnable (souvent 200-1000 tokens).

Embedding

Représentation numérique d'un texte (mot, phrase, document) sous forme de vecteur de nombres. Ces vecteurs capturent le sens sémantique : des textes similaires auront des embeddings proches dans l'espace vectoriel, ce qui permet de mesurer la similarité entre contenus.

Glossaire (2/4)

Few-shot

Capacité d'un modèle à réaliser une tâche après avoir vu quelques exemples (généralement 2 à 10) fournis dans le prompt. Ces exemples guident le modèle sur le format ou le type de réponse attendu, sans ré-entraînement.

Fine-tuning (Ajustement fin)

Le fine-tuning consiste à prendre un modèle déjà pré-entraîné sur une grande quantité de données générales, puis à le ré-entraîner sur un ensemble de données plus restreint et spécialisé. L'objectif est d'adapter le modèle à une tâche ou un domaine particulier tout en conservant ses capacités générales.

Machine Learning (Apprentissage automatique)

Le machine learning est une branche de l'intelligence artificielle qui permet aux systèmes informatiques d'apprendre et de s'améliorer à partir de données, sans être explicitement programmés pour chaque tâche. Les algorithmes identifient des patterns dans les données d'entraînement pour faire des prédictions.

Glossaire (3/4)

PEFT (Parameter-Efficient Fine-Tuning)

Le PEFT désigne un ensemble de techniques permettant d'ajuster (fine-tuner) un grand modèle de langage de manière économique en ressources, en ne modifiant qu'une petite fraction de ses paramètres plutôt que l'ensemble du modèle.

RAG (Retrieval-Augmented Generation)

Le RAG est une technique qui combine un modèle de langage avec un système de recherche d'informations. Avant de générer une réponse, le système cherche des informations pertinentes dans une base de données, puis utilise ces informations comme contexte pour produire sa réponse.

Retrieval (Récupération)

Étape du RAG consistant à rechercher et extraire les informations pertinentes d'une base de connaissances en fonction d'une requête. Typiquement, on convertit la requête en embedding puis on cherche les chunks les plus similaires dans la vector DB.

Glossaire (4/4)

Vector DB (Base de données vectorielle)

Base de données spécialisée pour stocker et rechercher des embeddings. Elle permet de trouver rapidement les vecteurs les plus similaires à une requête donnée grâce à des algorithmes de recherche de plus proches voisins (exemples : Pinecone, Weaviate, Chroma, Qdrant).

Zero-shot

Capacité d'un modèle à réaliser une tâche sans aucun exemple préalable. On lui donne simplement une instruction et il doit comprendre et exécuter la tâche en s'appuyant uniquement sur ses connaissances acquises lors de son entraînement initial.