Architecture technique d’un projet IA
Comprenez le pipeline technique complet, les rôles, les choix d’infrastructure et les décisions architecturales qui font la différence entre un POC et un système en production.
🎯 Objectifs
Comprendre le pipeline technique complet d’un projet IA
Savoir distinguer les rôles techniques (DS, MLE, MLOps, AI Architect)
Connaître les choix d’infrastructure (Cloud vs OnPrem vs Hybride)
Être capable de schématiser l’architecture d’un projet IA en entretien
1. Le pipeline IA complet
Un projet IA n’est pas juste « on prend un LLM et on l’appelle ». Voici les 6 étapes clés du pipeline, de la donnée à la production. Chaque étape a un impact direct sur le budget, le planning et les choix du PO.
1. Collecte & préparation des données
Sources : CRM, documents, logs, API partenaires. Défis en grand compte : silos de données (chaque service a son ERP), qualité hétérogène, données non labellisées. Le PO doit s’assurer que l’accès aux données est contractualisé avant le début du projet.
2. Feature engineering & embedding
Transformation des données brutes en représentations exploitables. Pour du texte : chunking + embedding vectors. Pour des images : extraction de features visuelles. Cas concret : embedding des justificatifs bancaires pour rechercher les documents similaires à une fraude connue.
3. Entraînement / Fine-tuning
Choix du modèle de base (GPT-4o, Claude, Llama, Mistral), constitution du dataset d’entraînement, budget compute (GPU). Le PO ne fait pas le fine-tuning, mais doit comprendre : combien ça coûte, combien de temps ça prend, et quel gain ça apporte par rapport au RAG.
4. Évaluation & validation
Métriques : précision, recall, F1-score. Jeux de test représentatifs. Détection de biais. Le PO valide les critères d’acceptance (ex : précision > 95%, recall > 90%) et participe aux tests UAT avec le métier.
5. Déploiement
Mise en production via API endpoint. Décisions : GPU vs CPU (latence vs coût), scaling (combien d’utilisateurs simultanés ?), A/B testing (comparer l’ancienne et la nouvelle version). Le PO priorise les bugs et les améliorations post-déploiement.
6. Monitoring & amélioration continue
Data drift (les données changent dans le temps), concept drift (le comportement attendu évolue), boucle de feedback (les corrections humaines améliorent le modèle). Le PO définit les alertes et le rythme de ré-entraînement.
2. Les rôles techniques (tableau)
Savoir qui fait quoi est essentiel en entretien. Voici les 5 rôles clés que vous côtoyerez.
| Rôle | Mission | Le PO travaille avec pour |
|---|---|---|
| Data Scientist | Modélisation, algorithmes, fine-tuning | Définir les métriques, valider le dataset |
| ML Engineer | Pipeline, déploiement, scaling | Choisir l’infra, planifier le release |
| Data Engineer | Données, pipelines ETL, qualité | Accès aux sources, qualité des données |
| MLOps | CI/CD, monitoring, gouvernance | Définir les alertes, les KPIs techniques |
| AI Architect | Vision technique, stack, sécurité | Valider l’architecture, les choix de modèles |
3. Cloud vs OnPrem vs Hybride
Question fréquente en entretien. Voici comment trancher.
| Critère | Cloud (AWS/Azure/GCP) | OnPrem | Hybride |
|---|---|---|---|
| Coût initial | Faible (pay-as-you-go) | Élevé (GPU clusters) | Moyen |
| Time-to-market | Rapide (semaines) | Lent (mois) | Moyen |
| Confidentialité | Données chez le provider | Données sur site | Données sensibles on-prem |
| Conformité | Dépend du provider | Maîtrise totale | Flexible |
| Scalabilité | Infinie (quasi) | Limitée hardware | Élastique |
| Maintenance | Zéro (SaaS) | Équipe dédiée | Partagée |
| Exemple bancaire | Chatbot service client | Détection fraude docs | Les deux combinés |
💡 Règle empirique
Données clients sensibles + modèles à haut risque AI Act → OnPrem ou Hybride. Use cases internes à faible risque → Cloud. En entretien, dites : « Je choisis toujours l’infra en fonction du niveau de risque AI Act et de la sensibilité des données. »
🌏 4. Exemple concret : Détection de fraude (banque)
Contexte
Une banque de détail reçoit 200 dossiers de prêt par semaine avec justificatifs (fiches de paie, avis d’imposition, relevés bancaires). Pertes annuelles sur faux documents : 2M€.
Pipeline
1. Réception du document (scan) → OCR + Vision
2. Embedding du document + métadonnées
3. Classification LLM : authentique / suspect / frauduleux
4. Si suspect ou frauduleux → escalade humaine avec analyse générée
5. Feedback humain → amélioration continue du modèle
Architecture retenue
Hybride : Vision/LLM sur cloud (API OpenAI pour la classification), embedding et stockage on-prem (données sensibles). Supervision humaine obligatoire (haut risque AI Act).
Résultats
Précision : 97%. Faux positifs : < 3%. Économies : 1,5M€/an. Temps de traitement : de 2 jours à 15 minutes.
✍️ Exercices
Exercice 1 : Pipeline chatbot RAG
Dessinez le pipeline complet d’un chatbot RAG pour une compagnie d’assurance. Quelles sont les 6 étapes ? Où se place le PO dans chaque étape ? Quels sont les risques ?
Exercice 2 : Choix d’infrastructure
Vous devez lancer un POC de 6 semaines pour un assistant commercial interne dans une banque. Quel type d’infrastructure choisissez-vous et pourquoi ? Quels critères font pencher la balance ?
Exercice 3 : Risques techniques
Identifiez 3 risques techniques dans le pipeline de détection de fraude et proposez une mitigation pour chacun.