Du modèle au produit : mon parcours AI Engineer.

Une progression en trois temps

1. Comprendre les données et comparer les modèles

   Des API préentraînées à la régression et à la classification : préparer les données, choisir une métrique et expliquer les prédictions.

2. Relier les composants d’une application

   API, RAG, stockage et MLOps : apprendre à relier le modèle au service, suivre ses versions et ses expériences, puis analyser son comportement.

3. Expérimenter et savoir conclure

   Vision, RL, données multimodales, orchestration et adaptation de LLM. Les résultats négatifs et les limites de protocole font partie du travail d’ingénierie.

Les réalisations, une par une

• P1 — Construire mon parcours IA
• P2 — Segmenter des vêtements
• P3 — Prévoir la consommation des bâtiments
• P4 — Comprendre l’attrition
• P5 — Servir un modèle par API
• P6 — Tracer les expériences de scoring
• P7 — Retrouver des événements avec un RAG
• P8 — Déployer et suivre le scoring
• P9 — Cadrer un projet IA
• P10 — Apprendre avec peu de labels
• P11 — Entraîner un agent LunarLander
• P12 — Construire un pipeline multimodal
• P13 — Orchestrer un assistant d’échecs
• P14 — Adapter un LLM médical

Ce que je veux mieux faire

Renforcer les évaluations indépendantes, la fidélité des réponses RAG et la cohérence des versions servies. Documenter plus clairement les coûts, l’exploitation et ce que je peux refaire seul. La compétence d’authentification du P5 reste non validée dans le retour OC.

Mon expérience full stack me permet de penser l’application entière. La formation me pousse à rendre aussi explicites les choix de données, de modèles et de protocoles, avec leurs limites.

Ce qui a changé dans ma vision du métier

Avant la formation, je voyais surtout le métier comme l’intégration de l’IA dans des applications. J’ai découvert le travail nécessaire pour préparer les données et comprendre le problème métier avant de choisir une solution. Aujourd’hui, je pense la chaîne entière : besoin, données, modèle, évaluation, déploiement et suivi.

Les choix techniques doivent servir la performance, les coûts et la sécurité du produit. Cela demande une vision globale, de la veille et la capacité à ajuster plusieurs composants. Les petits modèles open source adaptés à des besoins ciblés sont aussi une piste que je souhaite explorer.

Deux projets qui m’ont fait progresser

Consommation des bâtiments : comprendre avant de comparer

J’ai consacré beaucoup de temps à comprendre les modèles, les métriques et ce qui distingue une bonne évaluation d’un résultat trompeur. Ce projet m’a fait progresser en feature engineering et en prévention des fuites de données. Si je le recommençais, je traiterais plus soigneusement les valeurs manquantes et aberrantes, je travaillerais davantage la sélection et la création des variables et je comparerais plusieurs méthodes d’ajustement des hyperparamètres.

Scoring et MLOps : relier le modèle à un service

Le déploiement du modèle de scoring m’a permis de relier le travail de modélisation à une API, aux tests unitaires, au versionnage, à la conteneurisation et à la CI/CD. J’ai mieux compris pourquoi la mise en ligne et le suivi comptent autant que l’entraînement. L’apprentissage par renforcement m’a également beaucoup intéressé, notamment pour analyser le comportement d’un agent et tester des ajustements.

Ma priorité : mieux évaluer les RAG et les agents

Je veux améliorer la pertinence des documents retrouvés et la fidélité des réponses à leurs sources. Mon objectif est de construire des tests permettant de comparer les versions et de vérifier qu’une modification améliore réellement les réponses. C’est une priorité de progression, pas une capacité déjà démontrée par mes anciens résultats.

Expliquer les choix et mieux me situer

Dans mon quotidien, j’explique les usages de l’IA à différents niveaux de détail. Je cherche d’abord à justifier l’intérêt d’une solution avec une comparaison accessible, puis à approfondir si la personne le souhaite. Par exemple, expliquer pourquoi un LLM bénéficie de sources, d’outils et de contrôles rend les choix d’un RAG plus compréhensibles. Ces composants aident à réduire et détecter les erreurs ; ils ne garantissent pas une réponse correcte.

Je me reconnais dans la pédagogie, la curiosité, l’autonomie et la patience. La construction de ce portfolio m’aide à identifier plus clairement mes compétences et mes limites, et à mieux expliquer mes projets et mes décisions techniques.

La méthode et les preuves

Le bilan détaillé s’appuie sur les retours OC et les fichiers publics consultés dans les dépôts. Un résultat enregistré, un avis du jury et un fonctionnement actuel sont des preuves différentes. Aucun projet n’a été exécuté pendant cet audit.

Quatorze projets validés. Le statut du P14 a été actualisé sur confirmation de Pierre le 11 octobre 2026 ; les preuves techniques restent celles de l’audit du 9 octobre. La délivrance du titre RNCP niveau 7 a été confirmée par Pierre le 11 octobre 2026.