1. Partir du problème, pas de la solution
Commencez par ce que quelqu'un n'arrivait pas à faire. Qui subissait le problème, à quelle fréquence, et qu'est-ce qui rendait la situation coûteuse ou risquée ? Sans ce cadrage, votre interlocuteur ne peut évaluer ni la difficulté du projet ni la pertinence de vos décisions. Une phrase suffit souvent : « Les équipes support rouvraient manuellement des dossiers déjà traités parce que rien ne permettait de retrouver un historique éclaté sur trois systèmes. »
Précisez ensuite qui a formulé la demande et comment le succès était défini au départ. Beaucoup de projets IA échouent parce que ce point reste implicite ; montrer que vous l'avez posé explicitement est déjà un signal de séniorité.
2. Nommer les contraintes réelles
Les contraintes sont ce qui transforme un exercice en projet. Elles expliquent pourquoi la solution évidente n'était pas praticable, et donc pourquoi vos choix méritent d'être écoutés.
- Données : disponibilité, qualité, droits d'usage, confidentialité, volume, fraîcheur.
- Latence : temps de réponse acceptable pour l'usage réel, pas pour la démonstration.
- Coût : budget par requête ou par mois, et qui le supporte.
- Qualité : niveau d'erreur tolérable, et ce qui se passe quand le système se trompe.
- Organisation : équipe disponible, compétences internes, capacité à maintenir la solution après vous.
- Conformité : secteur régulé, traçabilité, hébergement, données personnelles.
3. Expliquer les choix, pas les nommer
C'est ici que la plupart des candidats basculent dans la récitation de stack. La règle est simple : chaque technologie citée doit être immédiatement suivie de la raison qui l'a fait retenir dans ce contexte précis. « Nous avons utilisé une base vectorielle » n'apprend rien ; « il fallait interroger des documents mis à jour quotidiennement sans réentraîner quoi que ce soit, donc nous sommes partis sur une recherche documentaire plutôt que sur un fine-tuning » situe votre raisonnement.
Version stack
« On a fait un RAG avec Python, LangChain, une base vectorielle, un modèle propriétaire pour la génération, le tout déployé sur Kubernetes avec un pipeline d'ingestion en batch et du monitoring. »
Version décisions
« Le besoin portait sur des documents internes révisés chaque semaine, avec des versions concurrentes du même texte. Le fine-tuning était exclu : le corpus bougeait trop vite. Nous sommes donc partis sur une recherche documentaire, en investissant d'abord dans le découpage et les métadonnées de version, parce que c'est là que se jouaient les réponses incohérentes. Pour la génération, nous avons pris le modèle le plus petit qui tenait notre seuil de qualité, avec une étape de reranking : le coût par requête devait rester compatible avec un usage quotidien par une centaine de personnes. »
Les deux versions décrivent le même projet. La seconde permet à votre interlocuteur d'évaluer un raisonnement ; la première ne permet que de cocher des mots-clés.
4. Assumer les arbitrages
Un projet sans arbitrage donne l'impression d'un exercice scolaire. Citez au moins une option sérieusement envisagée puis écartée, et dites pourquoi : contrainte de délai, coût, compétence indisponible dans l'équipe, dépendance jugée trop risquée. Précisez aussi ce que vous avez accepté de dégrader — la couverture fonctionnelle, la latence, l'exhaustivité — et au bénéfice de quoi.
Distinguez enfin ce que vous avez tranché vous-même de ce qui a été décidé par l'équipe ou imposé par le contexte. Cette honnêteté n'affaiblit jamais une candidature : elle est vérifiable en une question de suivi, et son absence l'est tout autant.
5. Montrer comment vous avez évalué
L'évaluation est le point qui sépare le plus nettement un prototype d'un système exploitable, et c'est souvent la partie la plus faible des présentations. Attendez-vous à des questions précises.
- Qui a défini ce qu'était une bonne réponse, et sur quel échantillon ?
- Comment saviez-vous qu'une modification améliorait le système plutôt que de déplacer le problème ?
- Aviez-vous un jeu d'évaluation stable, ou jugiez-vous au cas par cas ?
- Comment détectiez-vous une régression après un changement de modèle, de prompt ou d'index ?
- Que faisiez-vous des cas ambigus, ceux où même un humain hésite ?
Si le projet n'avait pas de dispositif d'évaluation, dites-le et expliquez comment vous vous en êtes passé, puis ce que vous feriez différemment aujourd'hui. C'est plus crédible qu'une évaluation reconstituée après coup.
6. Raconter le passage en production
Beaucoup de projets IA n'ont jamais quitté la démonstration, et les équipes techniques le savent. Si le vôtre est allé en production, c'est un atout majeur : décrivez le déploiement, la supervision mise en place, ce qui a cassé et ce que vous en avez tiré. Si le projet s'est arrêté avant, dites-le clairement et expliquez pourquoi — un arrêt lucide se raconte très bien.
- Ce qui était surveillé une fois en service, et par qui.
- Le comportement prévu en cas d'échec : repli, message, escalade vers un humain.
- Les garde-fous : filtrage, limites d'usage, périmètre volontairement restreint.
- Ce que le système ne savait pas faire, et comment cette limite était gérée côté produit.
7. Terminer par l'impact, sans chiffre inventé
Concluez par ce qui a changé pour les personnes concernées. Si vous disposez de chiffres réels et communicables, citez-les avec leur méthode de mesure. Sinon, décrivez la nature du résultat : un usage devenu quotidien, une tâche qui a disparu, une décision prise plus tôt, un périmètre repris par l'équipe interne. Un chiffre approximatif que vous ne pouvez pas défendre coûte plus cher qu'une description qualitative honnête.
Un dernier réflexe utile : terminez en reliant le projet au besoin de l'entreprise en face. « Ce qui m'intéresse chez vous, c'est que vous êtes exactement à l'étape où nous étions : le prototype fonctionne, la question devient la fiabilité et le coût. » Cette phrase transforme un récit en candidature.
Avant de présenter votre projet
Sept points, un par étape de la trame. Un point non couvert est celui à préparer en priorité.
- Je peux énoncer le problème en une phrase, du point de vue de celui qui le subissait.
- Je cite au moins deux contraintes réelles qui ont façonné la solution.
- Chaque technologie que je mentionne est justifiée par une raison de contexte.
- Je peux nommer une option écartée et expliquer pourquoi.
- Je sais dire comment la qualité était évaluée, et par qui.
- Je peux décrire l'état réel du projet : en production, arrêté, ou resté en prototype.
- Je décris l'impact sans avancer de chiffre que je ne pourrais pas défendre.
À retenir
- La trame : problème → contraintes → choix → arbitrages → évaluation → production → impact.
- Une technologie n'a de valeur dans le récit que si la décision qui l'a fait choisir est explicite.
- Les arbitrages écartés démontrent le niveau mieux que les fonctionnalités livrées.
- L'évaluation est le point le plus discriminant, et le plus souvent négligé.
- Mieux vaut un résultat qualitatif honnête qu'un chiffre invérifiable.
- AI Engineering
- Évaluation
- Cloud & production