D'accord, voici la traduction du texte source de l'anglais vers le français (Français), en suivant scrupuleusement toutes les instructions fournies.
Le génie logiciel en IA est l'un des métiers les mieux payés et à la croissance la plus rapide dans la tech en ce moment. Et la porte d'entrée n'a jamais été aussi grande.
La plupart des guides se trompent. Ils vous abreuvent de théorie, vous disent de maîtriser l'algèbre linéaire et les maths des réseaux de neurones, et vous perdent dès la deuxième semaine.
Ou alors ils vous noient sous 80 liens sans ordre ni conclusion, vous faisant passer plus de temps à décider quoi étudier qu'à étudier réellement.
J'ai parcouru les feuilles de route populaires, testé les outils qu'elles recommandent, et construit la version que je donnerais à un ami qui se reconvertit et qui a un vrai travail à côté.
Pas de diplôme en maths. Pas de plan sur 4 ans.
Quatre mois ciblés, un choix clair par compétence, des prompts réels que vous pouvez copier, et les erreurs qui tuent silencieusement la plupart des reconversions avant même qu'elles ne commencent.
Voici pourquoi je pense que le timing est crucial, puis le chemin complet.
Pourquoi la porte est ouverte (et je peux le prouver)
On vous a probablement dit que l'IA allait supprimer des emplois.
Voici la partie dont on parle moins : elle crée une catégorie d'emplois spécifique et bien rémunérée plus rapidement que presque tout le reste du marché, et le gardien habituel est en train de disparaître.
Le baromètre mondial des emplois dans l'IA 2026 de PwC a analysé plus d'un milliard d'offres d'emploi sur six continents. Trois conclusions sont importantes pour quiconque envisage une reconversion.
Premièrement, les emplois nécessitant des compétences en IA croissent environ huit fois plus vite que le marché global. Les postes liés à l'IA ont augmenté de 69 % tandis que le marché total de l'emploi a crû de 9 %.
Ce n'est pas une erreur d'arrondi. C'est une catégorie qui se démarque de tout ce qui l'entoure.
Deuxièmement, la prime salariale est réelle et augmente. Les travailleurs possédant des compétences en IA bénéficient d'une prime salariale de 62 % par rapport à des postes comparables sans ces compétences, contre 57 % l'année précédente.
Les entreprises paient plus, pas moins, pour les personnes capables de construire concrètement avec ces outils.
Troisièmement, et c'est ce qui change la donne pour les personnes en reconversion : l'exigence de diplôme diminue, et elle diminue le plus rapidement pour ces postes précisément.
PwC a constaté que la part des emplois augmentés par l'IA exigeant un diplôme est passée de 66 % à 59 % entre 2019 et 2024.
Pour les emplois où l'IA automatise une partie du travail, elle a encore plus baissé, passant de 53 % à 44 %. Les employeurs abandonnent le filtre du diplôme plus rapidement dans les métiers exposés à l'IA qu'ailleurs.
Il y a un autre chiffre qui mérite qu'on s'y attarde. Aux États-Unis, les postes de niveau débutant les plus exposés à l'IA ont augmenté de 35 % depuis 2019.
Sur la même période, les autres postes débutants ont diminué de 10 %. Le premier échelon de l'échelle de l'IA s'élargit tandis que le reste du marché d'entrée de gamme se contracte.
Maintenant, le contrepoint honnête, car je ne suis pas là pour vous vendre un rêve.
PwC a également constaté que les postes débutants exposés à l'IA exigent de plus en plus des compétences qui étaient auparavant réservées aux seniors : le jugement, la communication, la capacité à être responsable d'un résultat plutôt que d'une tâche.
La barre n'est pas plus basse partout. Elle a bougé. C'est moins « avez-vous le diplôme ? » et plus « pouvez-vous réellement faire fonctionner ceci et expliquer pourquoi ça marche ? ».
Considérez cela comme une mauvaise nouvelle si vous êtes un jeune diplômé sans expérience professionnelle. Considérez-le comme une bonne nouvelle si vous vous reconvertissez depuis une autre carrière, car vous possédez déjà ce qu'ils recherchent désormais.
Vous avez livré des projets. Vous avez traité avec des parties prenantes. Vous avez assumé des résultats sous pression.
Un jeune de 22 ans avec un diplôme en informatique ne l'a généralement pas fait. Si vous associez votre jugement existant aux compétences techniques de ce guide, vous n'êtes pas derrière les nouveaux diplômés.
Sur l'axe qui compte le plus pour les employeurs, vous êtes devant eux.
C'est l'avantage du reconverti, et presque aucune feuille de route ne vous en parle. Gardez-le en tête pendant les quatre mois. C'est la raison pour laquelle c'est réaliste pour vous en particulier.
Un mot rapide sur l'argent, car vous voudrez des chiffres réels avant de vous engager pour quatre mois.
Je donnerai la ventilation complète à la fin avec les sources, mais la version courte : à la mi-2026, Glassdoor estime le salaire moyen d'un ingénieur IA aux États-Unis à environ 143 500 $, avec une fourchette typique allant de 115 000 $ à 181 000 $.
Les postes seniors sont beaucoup plus élevés. Les recruteurs plaçant des personnes dans des postes de production IA rapportent des salaires de base de niveau intermédiaire se situant entre 155 000 $ et 200 000 $.
Ce ne sont pas des chiffres gonflés tirés d'un fil d'actualité. Ils sont actuels, et je vous montrerai d'où vient chacun d'eux.
Ce que fait réellement un ingénieur IA (la version en 60 secondes)
Avant le plan, tuons la plus grande source d'intimidation, car elle arrête plus de gens que n'importe quel obstacle technique.
Quand la plupart des gens entendent « ingénieur IA », ils imaginent quelqu'un dans un laboratoire entraînant un modèle géant à partir de zéro, entouré de GPU et de mathématiques qu'ils ne comprendront jamais.
C'est un métier différent. Cela s'appelle chercheur scientifique ou chercheur en ML, ils sont relativement peu nombreux, et cela nécessite généralement les diplômes avancés.
Le métier d'ingénieur IA qui croît huit fois plus vite que le marché est une tout autre chose.
Vous construisez des produits et des fonctionnalités par-dessus des modèles qui existent déjà. Vous prenez Claude, ou GPT, ou un modèle open source, et vous le faites faire un travail spécifique et fiable au sein d'une application réelle.
En pratique, cela signifie que vous vous connectez aux API des modèles, concevez les prompts et le contexte que vous leur fournissez, récupérez des données structurées, connectez le modèle à des outils et des bases de données, lui faites récupérer les bonnes informations, gérez tout ce qui peut mal tourner, et déployez le tout pour que de vraies personnes puissent l'utiliser.
C'est à mi-chemin entre le génie logiciel, le travail produit et l'IA appliquée. Vous êtes un constructeur, pas un chercheur.
Voici le test en une ligne que j'utiliserais. Si vous pouvez faire en sorte qu'un LLM effectue un travail spécifique de manière fiable dans une application, et que vous en comprenez assez pour le réparer quand il se casse, vous êtes un ingénieur IA. C'est tout.
Tout dans ce guide vise à vous amener à ce que cette phrase soit vraie pour vous.
Vous n'avez pas besoin de savoir comment fonctionne un transformer en interne. Vous n'avez pas besoin du calcul infinitésimal. Vous n'avez pas besoin d'être capable de dériver la rétropropagation.
Vous devez être un constructeur compétent qui comprend comment travailler avec ces modèles dans le monde réel.
C'est une compétence qui s'apprend, et quatre mois ciblés suffisent pour y devenir opérationnel.
À lire avant le Mois 1 : les 4 erreurs qui tuent les reconversions
Je mets ceci avant la feuille de route intentionnellement.
La plupart des guides enterrent les erreurs à la fin, mais les erreurs qui mettent fin à une reconversion surviennent à la deuxième semaine, pas au troisième mois. Si vous ne retenez qu'une seule section de ce guide, que ce soit celle-ci.
J'ai vu des gens, y compris une version antérieure de moi-même, commettre chacune de ces erreurs. Aucune n'est liée à l'intelligence.
Elles sont liées à la stratégie. Corrigez la stratégie et les quatre mois fonctionnent réellement.
Erreur 1 : Commencer par la théorie et les maths.
Vous êtes enthousiaste, vous voulez bien faire les choses, alors vous allez suivre un cours de machine learning et commencez par l'algèbre linéaire, la descente de gradient et les maths derrière les réseaux de neurones.
Trois semaines plus tard, vous avez regardé beaucoup de cours, vous ne pouvez rien construire, et vous vous sentez comme un imposteur. Alors vous abandonnez.
La solution : sautez cette étape. Pour le poste que vous visez, vous n'avez pas besoin de dériver les maths.
Vous devez construire.
Vous assimilerez les concepts dont vous avez réellement besoin au fur et à mesure que vous les rencontrerez dans des projets réels, et ils resteront parce qu'ils seront liés à quelque chose que vous avez construit.
La théorie d'abord est la raison la plus courante pour laquelle des personnes intelligentes abandonnent. Ne commencez pas par là.
Erreur 2 : Regarder des tutoriels au lieu de construire.
Celle-ci est sournoise parce qu'elle donne l'impression de progresser. Vous regardez un cours Python de quatre heures, vous acquiescez, vous avez l'impression d'avoir appris quelque chose. Ce n'est pas le cas.
Vous avez regardé quelqu'un d'autre apprendre quelque chose. Au moment où vous ouvrez un fichier vierge, il n'en reste rien.
La solution : la règle des 30 minutes. Pour chaque heure passée à regarder ou lire, passez au moins 30 minutes à construire quelque chose sans tutoriel ouvert.
Tapez les exemples vous-même. Cassez-les. Modifiez-les. Obtenez des erreurs et corrigez-les. Les erreurs sont l'apprentissage.
Une personne qui construit mal pendant quatre mois bat une personne qui regarde parfaitement pendant quatre mois, à chaque fois.
Les employeurs voient la différence en dix secondes en regardant votre GitHub.
Erreur 3 : Apprendre des outils au lieu de compétences.
Vous entendez dire que LangChain est la référence, alors vous vous plongez dans LangChain.
Six mois plus tard, le domaine a évolué, tout le monde utilise autre chose, et vos connaissances sur LangChain semblent perdues. Alors vous courez après le nouvel outil.
Puis celui-ci change aussi. Vous êtes toujours à la traîne parce que vous optimisez pour la mauvaise couche.
La solution : apprenez la compétence sous-jacente à l'outil. La compétence consistant à rédiger un prompt qui produit une sortie fiable n'expire pas lorsqu'un framework est mis à jour.
La compétence consistant à obtenir des données structurées d'un modèle, ou à évaluer si votre système fonctionne réellement, ou à décider quand une tâche nécessite un agent plutôt qu'un appel unique, celles-ci transcendent tous les outils qui existeront jamais.
Apprenez les outils comme un moyen de pratiquer les compétences, pas comme un objectif. Ce guide est organisé autour des compétences exactement pour cette raison.
Erreur 4 : Attendre de se sentir prêt pour construire en public.
Vous décidez que vous commencerez à partager votre travail, à postuler à des postes ou à proposer des services freelance une fois que vous serez « prêt ».
Vous ne vous sentirez jamais prêt. « Prêt » est un sentiment qui arrive après avoir commencé, pas avant.
Pendant ce temps, les personnes qui se font embaucher et qui trouvent des clients sont celles qui ont commencé à partager un travail imparfait des mois avant de se sentir qualifiées.
La solution : commencez à construire en public dès le Mois 1. Publiez la petite chose que vous avez faite. Rédigez ce que vous avez appris.
Mettez chaque projet sur GitHub le jour où vous le terminez, même les moches.
L'écart entre « j'apprends » et « je construis visiblement » est l'endroit où la plupart des reconvertis restent bloqués pendant un an. Comblez-le tôt.
Personne ne regarde d'assez près pour que vos premiers travaux vous embarrassent, et l'effet boule de neige commence le jour où vous débutez.
Gardez ces quatre points en vue tout au long du parcours.
La feuille de route ci-dessous est conçue pour les éviter tous par défaut : priorité aux compétences, priorité à la construction, indépendante des outils, publique dès le premier jour.
Mois 1 : Python et la plomberie
Votre objectif ce mois-ci : devenir un développeur Python fonctionnel, capable d'appeler une API, de gérer un petit projet et d'arrêter de chercher la syntaxe de base sur Google.
Pas un expert. Fonctionnel.
Tout dans les Mois 2 à 4 suppose que vous savez écrire du Python propre et travailler dans un terminal. C'est la fondation, et la brusquer vous nuira plus tard.
Voici ce qu'il faut intérioriser avant de commencer : le génie logiciel en IA est d'abord du génie logiciel. La partie IA repose sur une pile logicielle normale.
Si la pile en dessous est instable, la partie IA ne devient jamais fiable. Le Mois 1 consiste donc à devenir suffisamment à l'aise avec les bases pour qu'elles cessent de vous gêner.
Je vais vous donner un choix principal par compétence, avec une conclusion claire sur le pourquoi. Je ne vous donne délibérément pas cinq options par sujet. Le choix est l'ennemi de la dynamique.
Choisissez celui que je vous indique, et ne divergez que s'il ne fonctionne vraiment pas pour vous.
Python
Python est le langage de tout ce domaine. Presque toutes les bibliothèques, API, tutoriels et emplois que vous toucherez au cours des quatre prochains mois sont en Python. Vous l'apprenez, et tout le reste devient plus facile.
Mon choix : CS50P, Introduction à la Programmation avec Python de Harvard. Gratuit, rigoureux, et il vous force à résoudre des problèmes au lieu de regarder quelqu'un d'autre les résoudre.
Les ensembles de problèmes font toute la valeur. C'est plus exigeant qu'un cours YouTube doux, et c'est le but.
Vous voulez la version qui vous fait un peu lutter, car c'est dans la lutte que la compétence se forme.
Trouvez-le sur cs50.harvard.edu/python.
Si CS50P vous semble trop difficile en tant que débutant absolu, le cours Python de freeCodeCamp sur YouTube est une rampe d'accès plus douce, mais traitez-le comme un échauffement, pas comme l'événement principal.
Revenez à CS50P une fois que vous n'avez plus peur d'un fichier vierge.
Sur quoi se concentrer réellement, dans l'ordre approximatif : variables et types de données, boucles et conditions, fonctions, puis les types de collections (listes, dictionnaires, ensembles, tuples).
Ensuite, la gestion des fichiers et la lecture/écriture de JSON, que vous utiliserez constamment avec les API d'IA.
Puis juste assez de classes et de bases de la programmation orientée objet pour lire le code des autres sans paniquer.
Ensuite, la gestion des erreurs avec try et except.
Enfin, les environnements virtuels et pip, afin de pouvoir installer des packages sans casser votre système.
N'essayez pas de mémoriser tout cela. Comprenez-le assez bien pour le rechercher rapidement, et construisez avec jusqu'à ce que cela reste.
Votre objectif de construction du Mois 1 pour Python : un petit outil en ligne de commande qui fait quelque chose de réel.
Un suivi de dépenses qui lit et écrit dans un fichier JSON est un bon exemple. Ou un script qui appelle une API publique gratuite et imprime les résultats dans un format propre.
Quelque chose avec peut-être 60 à 100 lignes de votre propre code.
Peu importe si c'est moche. Ce qui compte, c'est que vous l'ayez écrit.
Apprendre avec l'IA dès le premier jour
C'est là que je ferais quelque chose que les anciennes feuilles de route ne font pas : utiliser l'IA pour apprendre l'IA, dès la première semaine.
Vous avez accès au meilleur tuteur patient jamais construit, et cela ne coûte rien sur les niveaux gratuits. Lorsque vous rencontrez une erreur que vous ne comprenez pas, ne passez pas 40 minutes sur un forum.
Collez-la dans Claude ou ChatGPT et demandez-lui d'expliquer l'erreur en langage clair et de vous guider vers la correction sans simplement vous donner la réponse.
Voici un prompt copiable que je mettrais en place dès le premier jour. Sauvegardez-le.
C'est le premier de plusieurs artefacts dans ce guide qui valent la peine d'être mis en signet.
Prompt : Votre partenaire d'apprentissage Python
(Cadre : Partenaire d'Apprentissage FAG, par AI Guides)
1Votre rôle : agir comme mon tuteur Python patient pendant que j'apprends à coder en tant que personne en reconversion.23Contexte à mon sujet :4- J'apprends Python pour devenir ingénieur IA.5- Je suis un débutant complet en codage, mais pas pour travailler dur.6- J'apprends mieux en faisant, pas en recevant des réponses toutes faites.78Ce que vous devez faire :9- Quand je colle une erreur, expliquez en langage clair ce qu'elle signifie et ce qui10 la cause probablement. Ne me donnez pas simplement le code corrigé.11- Guidez-moi d'abord vers la correction avec un indice. Ne montrez la solution complète12 que si je le demande deux fois.13- Quand je partage du code que j'ai écrit, dites-moi une chose qui fonctionne et une chose14 que je pourrais améliorer. Limitez-vous à ces deux points.15- Après avoir réussi quelque chose, posez-moi une question courte pour vérifier16 si j'ai vraiment compris.1718Règles :19- Pas de jargon sans une définition d'une ligne en langage clair à côté.20- Supposez que je veux apprendre, pas seulement réussir. Un peu plus lent, c'est bien.21- Si je suis sur le point de prendre une mauvaise habitude, dites-le directement et gentiment.2223Format : conversationnel, court, un concept à la fois.
Utilisez-le chaque jour de ce mois. Il transforme les parties frustrantes de l'apprentissage du code en une conversation plutôt qu'un mur.
Cela vous rend également fluide dans l'art du prompting, qui est la compétence de base du Mois 2, avant même que vous sachiez ce qui se passe.
Une mise en garde pour ne pas prendre la mauvaise habitude : utilisez l'IA pour comprendre et débloquer, pas pour écrire le tout à votre place.
Si vous la laissez écrire votre code pendant que vous regardez, vous revenez à l'Erreur 2.
Faites-lui expliquer. C'est vous qui tapez.
Git et GitHub
Git est la façon dont les développeurs sauvegardent, versionnent et partagent le code.
GitHub est l'endroit où votre travail vit en public et devient un portfolio.
Vous utiliserez les deux constamment, et pour une personne en reconversion, GitHub est ce qui se rapproche le plus d'un CV jusqu'à ce que vous en ayez un.
Mon choix : GitHub Skills. Gratuit, interactif, et construit par GitHub à l'intérieur de GitHub lui-même, donc vous apprenez l'outil en l'utilisant. Commencez par là plutôt que de lire sur Git de manière abstraite.
Trouvez-le sur skills.github.com.
Si le modèle de branchement et de fusion vous déroute, et il déroute tout le monde au début, l'outil visuel Learn Git Branching vous le fait comprendre en vous laissant voir les branches bouger.
Sur quoi se concentrer : la boucle principale de init, add, commit, push, et pull. Ensuite, le branchement et la fusion.
Ensuite, ce qu'est un fichier .gitignore et pourquoi vous ne devez jamais commettre de secrets ou de clés API dans un dépôt public, ce qui est extrêmement important une fois que vous travaillez avec des API payantes.
Ensuite, comment rédiger un README de base, car vos README feront un vrai travail dans votre recherche d'emploi plus tard.
L'habitude à prendre ce mois-ci : chaque projet que vous touchez, même un script de 20 lignes, va dans un dépôt GitHub le jour où vous le créez.
C'est la correction de l'Erreur 4 en pratique. Vous construisez en public, discrètement, dès le début.
Au Mois 4, vous aurez une trace de travail au lieu d'un profil vierge.
Le terminal
Vous exécuterez des scripts, installerez des packages et gérerez des projets à partir de la ligne de commande constamment.
Être lent ou avoir peur dans le terminal est un vrai frein pour tout le reste, et c'est une chose facile à corriger.
Mon choix : un court cours de terminal pour débutants couvrant les bases, puis vivez dedans. Les supports du « Missing Semester » du MIT vont plus loin si vous le souhaitez, mais pour le Mois 1, vous n'avez besoin que de la navigation et de l'exécution.
Apprenez cd, ls, pwd, mkdir, et rm pour vous déplacer et gérer les fichiers.
Apprenez cat et grep pour lire et rechercher.
Apprenez à exécuter un script Python depuis le terminal et à définir une variable d'environnement, ce dont vous aurez besoin dès que vous manipulerez des clés API.
Vous n'avez pas besoin de devenir un as du shell. Vous devez arrêter d'hésiter.
Une semaine à utiliser le terminal pour tout, même les choses que vous feriez normalement avec une souris, vous y amène.
API, JSON et HTTP
C'est le pont vers le Mois 2.
Dès le premier jour de construction avec les LLM, vous ferez des appels API, ce qui signifie que vous devez comprendre comment fonctionnent les API web avant de toucher aux outils d'OpenAI ou d'Anthropic.
Mon choix : l'aperçu HTTP de la MDN Web Docs pour les concepts, plus la documentation de la bibliothèque Python requests pour le faire en code.
MDN explique comment fonctionnent les requêtes et les réponses plus clairement que tout ce qui est gratuit.
Ensuite, requests vous montre comment effectuer ces appels en Python en quelques lignes.
Sur quoi se concentrer : ce que sont les requêtes GET et POST et comment les faire en Python.
Lire et écrire du JSON, qui est le format que parle chaque API d'IA.
Les codes de statut HTTP et ce que signifient les plus courants, en particulier 200 pour le succès, 401 pour une mauvaise clé API, 429 pour la limitation de débit et 500 pour une erreur serveur, car vous les verrez tous constamment.
Ce qu'est une clé API et comment fonctionne l'authentification de base.
Et une légère introduction à ce que font async et await en Python, ce dont vous aurez besoin lorsque vous commencerez à diffuser des réponses de modèles plus tard.
N'approfondissez pas async maintenant.
Sachez juste que ça existe et quel problème cela résout approximativement.
Votre objectif de construction ici : un script Python qui appelle une API publique gratuite, qui ne nécessite pas de clé comme l'API météo Open-Meteo, et imprime le résultat sous forme de sortie formatée propre.
C'est une version miniature de exactement ce que vous ferez tout au long du Mois 2, juste sans la partie IA pour l'instant.
Une note rapide sur SQL
Vous n'avez pas besoin d'être un spécialiste des données, mais vous aurez régulièrement besoin de consulter et d'interroger des données, et le SQL de base vous sauve constamment.
Mon choix est SQLBolt, qui est gratuit, interactif et vous enseigne le cœur de SQL en environ 20 courtes leçons dans le navigateur.
Trouvez-le sur sqlbolt.com.
Concentrez-vous sur SELECT, WHERE, GROUP BY, JOIN et ORDER BY.
C'est suffisant pour l'instant.
Vous pourrez approfondir dès qu'un projet l'exigera.
Jalon du Mois 1
À la fin du mois, vous devriez être capable d'écrire un programme Python qui lit et écrit des fichiers, appelle une API et gère ses propres erreurs sans planter.
Vous devriez versionner ce code avec Git et l'avoir dans un dépôt GitHub.
Vous devriez vous déplacer dans le terminal sans hésiter. Vous devriez comprendre ce qu'est une requête HTTP et en faire une en Python.
Et vous devriez être capable d'exécuter une requête SQL de base.
Si vous pouvez faire ces choses, vous avez les bases.
La plupart des gens qui abandonnent n'arrivent jamais ici, et y arriver est vraiment la partie la plus difficile car c'est la moins excitante.
Cela devient plus amusant à partir du Mois 2, car à partir de là, vous construisez avec l'IA.
Mois 2 : Construire avec les API LLM
Votre objectif ce mois-ci : construire des fonctionnalités réelles basées sur l'IA en utilisant les API de modèles.
À la fin, vous devriez être à l'aise pour rédiger des prompts qui produisent des résultats fiables, obtenir des données structurées d'un modèle, faire en sorte que le modèle appelle vos propres fonctions, gérer une conversation et gérer tout ce qui peut casser.
C'est le cœur de tout le métier. Tout le reste après cela s'appuie là-dessus.
C'est le mois où cela commence à devenir réel. Vous arrêtez la configuration et commencez à faire faire des choses aux modèles.
Prenez votre temps ici.
La profondeur au Mois 2 rapporte plus que la profondeur ailleurs dans le guide.
Le prompting qui fonctionne réellement
Le prompting, ce n'est pas demander gentiment à un chatbot.
C'est la compétence consistant à rédiger des instructions qui produisent une sortie cohérente et fiable à partir d'un système fondamentalement probabiliste.
En tant qu'ingénieur IA, vous passerez plus de temps ici que vous ne le pensez, et devenir bon dans ce domaine est la chose la plus efficace que vous puissiez faire ce mois-ci.
Mon choix : le tutoriel interactif de prompt engineering d'Anthropic sur GitHub. C'est la ressource la plus pratique qui existe, divisée en chapitres avec des exercices réels que vous exécutez contre l'API Claude.
Vous pratiquez l'écriture et la correction de prompts vous-même au lieu de lire à ce sujet, ce qui, si vous vous souvenez de l'Erreur 2, est tout l'intérêt.
Trouvez-le dans le dépôt anthropics/prompt-eng-interactive-tutorial. Une fois que vous l'avez parcouru, les docs officielles de prompt engineering d'Anthropic et d'OpenAI sont la référence à laquelle vous reviendrez.
Sur quoi se concentrer : la différence entre un message système et un message utilisateur, et pourquoi cette différence est importante.
Pourquoi la spécificité bat la politesse à chaque fois.
Le prompting par chaîne de pensée, où vous demandez au modèle de raisonner étape par étape avant de répondre, ce qui améliore mesurablement les résultats sur tout ce qui contient de la logique.
Utiliser des exemples dans votre prompt, appelé prompting few-shot, pour montrer au modèle le format que vous souhaitez.
Et développer un ressenti pour la façon dont de petits changements de formulation produisent de grands changements de sortie, ce qui ne vient qu'en le faisant beaucoup.
Un exercice de construction qui enseigne cela rapidement : prenez une tâche réelle, comme résumer un document ou classer un commentaire, et écrivez cinq prompts différents pour elle.
Exécutez les cinq.
Comparez les sorties côte à côte. Vous verrez immédiatement à quel point la conception du prompt influence la fiabilité, et cette leçon reste mieux que n'importe quel cours.
Sorties structurées
Dans une application réelle, vous ne voulez presque jamais un paragraphe de texte en retour d'un modèle.
Vous voulez des données structurées que votre code peut analyser, stocker et utiliser. Les sorties structurées résolvent cela en forçant le modèle à retourner des données qui correspondent à un schéma que vous définissez.
C'est l'une de ces compétences qui sépare une démo de quelque chose qui fonctionne réellement dans un logiciel.
Mon choix : la bibliothèque Instructor pour Python, soutenue par les docs officielles sur les sorties structurées d'OpenAI et d'Anthropic.
Instructor est le moyen le plus propre d'obtenir des données structurées de n'importe quel modèle majeur en utilisant Pydantic, qui est une bibliothèque Python pour définir la forme de vos données.
Cela fonctionne avec différents fournisseurs avec le même code et réessaie automatiquement lorsque le modèle retourne quelque chose de mal formé.
C'est proche de ce que beaucoup d'ingénieurs en activité utilisent réellement, ce qui le rend utile à apprendre sur des projets réels plutôt qu'une version jouet.
Sur quoi se concentrer : définir un modèle Pydantic qui décrit les données que vous voulez, passer ce schéma à l'API et gérer le cas où le modèle refuse ou retourne quelque chose d'inattendu.
Comprendre la différence entre les vraies sorties structurées, où le schéma est appliqué, et le mode JSON plus lâche, où il n'est pas garanti.
Voici votre deuxième artefact à mettre en signet, un modèle de prompt pour une extraction structurée fiable qui fonctionne même avant d'ajouter une bibliothèque par-dessus.
Prompt : Extraction de données structurées
(Cadre : Extracteur FAG, par AI Guides)
1Tu es un extracteur de données structurées. Ta tâche est d'extraire des informations2d'un texte saisi et de les retourner dans un format JSON valide correspondant au schéma3fourni.45Règles :6- Retourne UNIQUEMENT le JSON. Aucun texte d'introduction ou de conclusion.7- Si une information est manquante, utilise null pour ce champ.8- Ne fais pas de suppositions. Extrais uniquement ce qui est explicitement présent9 dans le texte.10- Assure-toi que le JSON est valide et peut être analysé.1112Schéma de sortie :13{14 "nom_entite": "nom ou titre de l'entité principale",15 "type": "catégorie de l'entité (personne, organisation, lieu, événement, produit)",16 "attributs": {17 "attribut_cle_1": "valeur_1",18 "attribut_cle_2": "valeur_2"19 },20 "resume": "résumé concis de l'information en une phrase"21}2223Texte d'entrée :24{texte_entree}
Appels de fonction (Tool Use)
C'est là que le modèle cesse d'être une boîte de dialogue et devient un moteur qui déclenche des actions dans votre système.
L'appel de fonction permet au modèle de demander à votre code d'exécuter une fonction spécifique, comme rechercher une base de données, envoyer un email ou effectuer un calcul, et d'utiliser le résultat dans sa réponse.
C'est ce qui transforme un chatbot en un agent capable d'agir.
Mon choix : les guides officiels d'appel de fonction d'OpenAI et d'Anthropic, plus la documentation de la bibliothèque Instructor pour la partie validation.
Les docs officielles vous montrent le mécanisme. Instructor vous montre comment le faire proprement à grande échelle.
Sur quoi se concentrer : définir des schémas de fonction que le modèle peut appeler, comprendre comment le modèle décide quelle fonction appeler et avec quels arguments, gérer le cycle requête-réponse où le modèle demande un outil, votre code l'exécute, et vous renvoyez le résultat au modèle.
Et le modèle le plus important : ne faites jamais confiance aux arguments générés par le modèle sans validation. Validez toujours les entrées des fonctions comme vous le feriez pour une entrée utilisateur.
Votre objectif de construction pour le Mois 2 : un outil de ligne de commande qui prend une requête en langage naturel, utilise un LLM pour la comprendre, appelle une API externe (comme une recherche météo ou une recherche web simulée) en fonction de la requête, et formate le résultat.
C'est votre premier système « agentique » réel, même s'il est simple.
Gestion des erreurs et fiabilité
Les LLM échouent de manière intéressante et imprévisible. Votre travail consiste à construire des systèmes qui gèrent ces échecs avec élégance.
Concentrez-vous sur la gestion des erreurs de l'API (timeouts, erreurs de taux, pannes de service), la gestion des sorties mal formées (JSON qui ne s'analyse pas, contenu refusé), la mise en œuvre de nouvelles tentatives avec backoff exponentiel, et la construction de validations de base pour vérifier que la sortie a du sens avant de l'utiliser.
Jalon du Mois 2
À la fin du mois, vous devriez être capable de construire un pipeline qui prend une entrée, la traite via un LLM avec un prompt bien conçu, obtient une sortie structurée, et gère les erreurs courantes.
Vous devriez être capable d'expliquer pourquoi vous avez conçu votre prompt d'une manière particulière et ce que vous feriez s'il échouait.
Mois 3 : RAG, agents et systèmes
Votre objectif ce mois-ci : construire des systèmes qui font plus qu'un seul appel API.
À la fin, vous devriez être capable de construire un système de Retrieval-Augmented Generation (RAG) qui permet à un modèle de répondre à partir de vos propres données, de construire un agent simple qui peut utiliser plusieurs outils et prendre des décisions, et de comprendre comment évaluer si votre système fonctionne réellement.
C'est le mois où vous passez de la construction de fonctionnalités à la construction de systèmes.
RAG : donner à votre modèle des connaissances
Le problème fondamental des LLM est qu'ils ne connaissent que ce sur quoi ils ont été entraînés. Si vous voulez qu'ils répondent à partir de votre documentation, de vos emails ou de votre base de connaissances, vous devez leur fournir ces informations.
C'est ce que fait RAG. Vous récupérez les documents pertinents à partir d'une base de données vectorielle, vous les insérez dans le contexte du modèle, et il répond en fonction de ces documents.
Mon choix : le tutoriel RAG de LangChain ou LlamaIndex, selon celui qui vous semble le plus clair. Les deux sont bons. Commencez par l'un, et si la terminologie vous déroute, essayez l'autre.
Ne passez pas des semaines à choisir. Prenez-en un et construisez.
Sur quoi se concentrer : le concept d'embedding et pourquoi les vecteurs sont utilisés pour la recherche sémantique. Le découpage des documents en morceaux de la bonne taille. Le choix d'une base de données vectorielle (Chroma est un bon point de départ). La construction d'une boucle de récupération de base où vous interrogez, récupérez et générez.
Et le piège le plus courant : la qualité de la récupération est plus importante que la qualité du prompt. Si vous récupérez les mauvais documents, le meilleur prompt du monde ne vous aidera pas.
Votre objectif de construction pour RAG : un chatbot qui répond à des questions sur un ensemble de documents que vous fournissez. Prenez une documentation de projet open source, ou une politique d'entreprise, ou même un ensemble d'articles de blog, et construisez un système qui peut y répondre.
Agents : laisser le modèle prendre des décisions
Un agent est un LLM qui peut décider quels outils utiliser et dans quel ordre pour accomplir une tâche.
C'est différent d'un simple appel de fonction car l'agent peut raisonner sur plusieurs étapes, choisir différents outils en fonction du résultat, et persévérer jusqu'à ce que la tâche soit terminée ou échoue.
Mon choix : le guide de construction d'agents d'Anthropic (considérez-le comme la référence), plus le tutoriel OpenAI Agents SDK pour une implémentation pratique.
Anthropic explique la philosophie. OpenAI montre le code.
Sur quoi se concentrer : la boucle agentique de base : l'agent reçoit une tâche, décide d'un outil, l'appelle, reçoit le résultat, et décide de la prochaine étape. La gestion des boucles infinies (toujours définir un nombre maximum d'itérations). La journalisation de ce que l'agent fait afin de pouvoir déboguer quand il fait quelque chose d'inattendu.
Et la règle d'or : les agents sont puissants mais imprévisibles. Utilisez-les lorsque vous avez besoin de flexibilité, pas lorsque vous avez besoin de fiabilité. Pour les tâches prévisibles, un flux de travail codé en dur est meilleur.
Votre objectif de construction pour les agents : un agent de recherche qui peut planifier une requête, rechercher sur le web (ou une base de données simulée), synthétiser les résultats et retourner un résumé. C'est votre premier système multi-étapes.
Évaluation : votre système fonctionne-t-il réellement ?
C'est la compétence la plus sous-estimée dans le génie logiciel en IA. La plupart des gens construisent quelque chose, le testent sur trois exemples, et supposent que ça marche.
Ensuite, ils le déploient et tout se casse.
L'évaluation est la pratique consistant à tester systématiquement votre système sur un ensemble de cas pour savoir s'il fonctionne réellement.
Mon choix : les guides d'évaluation de LangSmith ou Weights & Biases, plus le concept de construire votre propre ensemble d'évaluation.
Les outils vous aident à exécuter des évaluations. L'ensemble d'évaluation est ce qui rend les évaluations utiles.
Sur quoi se concentrer : construire un ensemble de test de 20 à 50 paires entrée-sortie attendue qui couvrent les cas normaux, les cas limites et les cas d'échec attendus. Exécuter votre système sur l'ensemble de test et mesurer la précision, l'exhaustivité ou la qualité. Utiliser un LLM comme juge pour évaluer la qualité lorsque la réponse correcte est subjective.
Et l'habitude la plus importante : évaluez avant de déployer. Toujours.
Jalon du Mois 3
À la fin du mois, vous devriez être capable de construire un système RAG qui répond à partir de documents personnalisés, un agent qui utilise plusieurs outils pour accomplir une tâche, et un ensemble d'évaluation de base qui vous indique si votre système fonctionne.
Vous devriez être capable d'expliquer pourquoi vous avez choisi RAG plutôt que le fine-tuning pour un problème donné, et vice versa.
Mois 4 : Déploiement, portfolio et recherche d'emploi
Votre objectif ce mois-ci : transformer vos compétences en un portfolio que les employeurs peuvent voir, et commencer à postuler.
À la fin, vous devriez avoir au moins un projet déployé que vous pouvez montrer, un profil GitHub qui raconte une histoire, et un processus pour postuler à des emplois qui ne repose pas sur l'envoi de CV dans le vide.
Déploiement : mettre votre travail en ligne
Un projet sur votre machine locale ne prouve rien. Un projet déployé que les gens peuvent utiliser prouve tout.
Mon choix : Render ou Railway pour le déploiement simple d'applications web. Les deux ont des niveaux gratuits et sont conçus pour les développeurs individuels.
Si vous voulez quelque chose d'encore plus simple pour une démo rapide, Streamlit Community Cloud vous permet de déployer des applications Streamlit en vous connectant à votre dépôt GitHub.
Sur quoi se concentrer : créer une application web simple (même avec Streamlit) qui expose votre projet IA. Configurer les variables d'environnement pour les clés API. Gérer les erreurs avec élégance dans l'interface utilisateur. Et écrire un bon fichier README qui explique ce que fait le projet, comment il fonctionne et ce que vous avez appris.
Votre objectif de construction pour le déploiement : prenez l'un de vos projets du Mois 2 ou 3 et déployez-le afin que n'importe qui puisse l'essayer avec un lien.
Votre portfolio GitHub
Votre GitHub est votre CV pour les emplois en IA. Les recruteurs le regarderont avant votre CV papier.
Mon choix : pas de cours pour cela. C'est une question d'habitude et de stratégie.
Sur quoi se concentrer : avoir 3 à 5 projets bien documentés. Chaque projet doit avoir un README clair qui explique le problème, votre approche, la pile technologique et ce que vous avez appris. Écrire du code propre et commenté. Avoir un historique de commits qui montre un travail régulier (pas un énorme commit le dernier jour).
Et la pièce la plus importante : inclure un projet qui résout un problème réel, même petit. Un projet qui fait quelque chose d'utile bat un projet qui utilise une technologie impressionnante mais ne fait rien.
Postuler : contourner le bruit
Postuler à des emplois via des portails d'emploi est un jeu de nombres avec de faibles chances. Les références et la visibilité fonctionnent mieux.
Mon conseil : construire en public sur LinkedIn ou Twitter/X. Partager ce que vous apprenez et construisez. Interagir avec les publications des personnes travaillant dans le domaine. Postuler à des emplois via les pages carrières, mais aussi contacter directement les recruteurs et les responsables du recrutement avec un message personnalisé montrant votre travail.
Adapter votre CV et votre portfolio à chaque emploi. Mettre en évidence les projets qui correspondent à la description du poste. Et se préparer aux entretiens en pratiquant les questions d'entretien courantes sur l'IA et le génie logiciel.
Jalon du Mois 4
À la fin du mois, vous devriez avoir au moins un projet déployé, un profil GitHub avec 3 à 5 projets, et avoir postulé à au moins 10 à 20 emplois avec des candidatures personnalisées.
Vous devriez être capable d'expliquer votre parcours, vos compétences et vos projets de manière convaincante en 60 secondes.
La ventilation des salaires (avec sources)
Voici les chiffres promis, avec des sources que vous pouvez vérifier.
Comme indiqué précédemment, Glassdoor (juin 2026) rapporte un salaire moyen d'ingénieur IA aux États-Unis d'environ 143 500 $, avec une fourchette de 115 000 $ à 181 000 $.
Levels.fyi, qui suit la rémunération dans les entreprises technologiques, montre des totaux médians pour les ingénieurs IA de niveau intermédiaire (IC3/IC4) dans les grandes entreprises technologiques se situant entre 180 000 $ et 250 000 $, y compris les actions.
Les données salariales de PwC confirment la prime de 62 % pour les compétences en IA par rapport aux postes sans IA.
Le rapport 2025 d'Anthropic sur l'économie de l'IA note que les salaires des ingénieurs de prompts et des spécialistes de la mise en œuvre de l'IA augmentent plus rapidement que ceux des rôles d'ingénieur logiciel traditionnels.
Ces chiffres sont cohérents sur plusieurs sources et représentent le marché actuel à la mi-2026.
Les outils que j'utiliserais (et pourquoi)
Plutôt que de vous donner une liste de 50 outils, voici ceux que j'utiliserais si je recommençais aujourd'hui, avec une brève raison pour chacun.
Pour l'apprentissage : CS50P pour Python, le tutoriel de prompt engineering d'Anthropic pour le prompting, et SQLBolt pour SQL. Tous gratuits, tous pratiques.
Pour le développement : VS Code comme éditeur, avec l'extension GitHub Copilot (gratuite pour les étudiants et les mainteneurs open source). Claude ou ChatGPT pour l'assistance à la programmation et le débogage.
Pour la construction : Instructor pour les sorties structurées, Chroma pour les bases de données vectorielles (commencez ici, pas avec Pinecone), et LangChain ou LlamaIndex pour les flux RAG (mais seulement après avoir compris les concepts sous-jacents).
Pour le déploiement : Render ou Railway pour les applications web, Streamlit pour les démos rapides, et GitHub Pages pour les sites de portfolio statiques.
Pour la recherche d'emploi : LinkedIn pour le réseautage et la recherche d'emploi, Levels.fyi pour les données salariales, et Glassdoor pour les avis sur les entreprises.
Le plan d'action final
Voici le résumé exécutif de tout ce guide.
Mois 1 : Apprenez Python, Git, le terminal, les bases des API et SQL. Construisez un petit outil en ligne de commande. Utilisez l'IA pour apprendre l'IA.
Mois 2 : Maîtrisez le prompting, les sorties structurées et les appels de fonction. Construisez un pipeline qui utilise un LLM pour effectuer une tâche réelle.
Mois 3 : Construisez un système RAG, un agent simple et un ensemble d'évaluation. Passez des fonctionnalités aux systèmes.
Mois 4 : Déployez un projet, construisez votre portfolio GitHub et commencez à postuler. Construisez en public et postulez de manière ciblée.
Tout au long : Évitez les quatre erreurs. Construisez en public. Utilisez l'IA pour apprendre. Et n'oubliez pas votre avantage de reconverti.
Vous avez ce qu'il faut. Commencez aujourd'hui.
1Votre mission : extraire des données structurées du texte que je fournis et les retourner2sous forme de JSON propre.34Ce qu'il faut faire :5- Lisez attentivement le texte d'entrée.6- Extrayez uniquement les champs listés ci-dessous dans la section Sortie.7- Si un champ est absent du texte, utilisez null. Ne devinez pas et n'inventez pas.8- Retournez uniquement l'objet JSON. Pas d'explication, pas de markdown, pas de préambule.910Règles :11- Chaque valeur doit pouvoir être retracée jusqu'à quelque chose dans le texte d'entrée.12- Dates au format AAAA-MM-JJ. Les nombres comme des nombres, pas des chaînes.13- Si le texte est ambigu, préférez null à une réponse fausse mais confiante.1415Sortie : un objet JSON avec ces champs :16{17 "field_one": string ou null,18 "field_two": number ou null,19 "field_three": liste de chaînes ou liste vide20}2122Texte d'entrée :23[COLLEZ LE TEXTE ICI]
La note sur l'échec testé, parce que je vous ai promis la version honnête : la première fois que vous faites cela, le modèle va parfois encapsuler le JSON dans des blocs de code markdown, ou ajouter une phrase amicale avant, et votre analyseur va s'étouffer.
C'est normal. La solution consiste à supprimer les blocs de code avant l'analyse, et à être explicite dans le prompt que vous voulez uniquement l'objet JSON, ce que le modèle ci-dessus fait.
Une fois que vous avez rencontré cela et que vous l'avez géré, vous le gérerez pour toujours.
Votre objectif de construction : un analyseur de reçus ou de factures.
Nourrissez-le avec un texte brut et désordonné comme « Facture 123, 45,99 $ pour 3 widgets, échéance le 30 mars » et récupérez un objet structuré propre avec le numéro de facture, le montant, le nombre d'articles et la date d'échéance.
C'est un petit outil vraiment utile et un bon projet pour votre portfolio.
Appel d'outils (Tool calling)
L'appel d'outils est ce qui transforme un générateur de texte en quelque chose qui peut agir : chercher sur le web, interroger une base de données, appeler votre API, exécuter du code.
C'est l'une des compétences les plus importantes de tout ce guide, et c'est le fondement de tout ce qui se trouve dans le Mois 3.
Le modèle mental qui le rend clair : le modèle n'exécute pas vos fonctions.
Il regarde la conversation, décide qu'un outil doit être utilisé, et retourne une requête structurée nommant la fonction et les arguments.
Votre code exécute la fonction et transmet le résultat au modèle. Le modèle est le décideur. Votre code est les mains.
Mon choix : le guide d'appel de fonction d'OpenAI et la documentation sur l'utilisation des outils d'Anthropic, lus ensemble.
Les concepts sont identiques chez les deux, la syntaxe diffère légèrement, et voir les deux rend le modèle sous-jacent évident.
Ensuite, travaillez sur un exemple de notebook exécutable, comme celui du cookbook OpenAI, afin de voir la boucle complète de bout en bout au lieu de morceaux.
Sur quoi se concentrer : décrire clairement vos fonctions dans un schéma, analyser la réponse d'appel d'outil du modèle, exécuter la fonction et renvoyer le résultat, et gérer le cas où le modèle décide qu'aucun outil n'est nécessaire.
La qualité de vos descriptions d'outils est plus importante que ce que les débutants attendent, ce qui est un thème qui revient en force au Mois 3.
Votre objectif de construction : un petit assistant avec trois outils, comme get_weather, calculate, et search_notes où search_notes cherche simplement dans un dictionnaire codé en dur.
Connectez-les tous et regardez le modèle décider lequel appeler en fonction de ce que vous demandez.
Le moment où vous le voyez choisir le bon outil tout seul, le concept s'installe définitivement.
État de la conversation et streaming
Deux compétences plus petites mais essentielles complètent le mois.
Les modèles n'ont aucune mémoire entre les appels. Une conversation est quelque chose que vous gérez en envoyant l'historique complet des messages à chaque requête.
Comprendre cela est fondamental, et cela surprend presque tout le monde au début.
Mon choix est la documentation sur les messages d'OpenAI et d'Anthropic.
Concentrez-vous sur la façon dont le tableau de messages est structuré, pourquoi vous ajoutez à la fois les messages de l'utilisateur et les réponses du modèle, ce qui se passe lorsque vous dépassez la fenêtre de contexte, et les stratégies de base pour élaguer les anciens messages.
Construisez un simple chatbot terminal multi-tours qui conserve l'historique et dispose d'une commande de réinitialisation. C'est petit et cela enseigne complètement le concept.
Le streaming signifie afficher la sortie du modèle au fur et à mesure qu'elle est générée, mot par mot, au lieu de faire attendre l'utilisateur pour l'ensemble.
Cela rend les applications considérablement plus rapides.
Mon choix est la documentation officielle sur le streaming de l'un ou l'autre fournisseur, plus l'article clair de Simon Willison sur le fonctionnement du streaming en dessous.
Concentrez-vous sur la définition de l'option stream, l'itération sur les morceaux, et l'assemblage de la réponse complète à partir des pièces.
Pour tout ce qu'une vraie personne utilisera, le streaming est presque toujours le bon choix.
Personne ne veut fixer un spinner pendant dix secondes.
Coût, échec et une idée de sécurité
Trois choses qui séparent un projet de loisir de quelque chose que vous mettriez devant des utilisateurs.
Coût et tokens : les modèles facturent par token, ce qui correspond à environ les trois quarts d'un mot.
Les tokens d'entrée et de sortie sont tarifés différemment.
Apprenez à estimer ce qu'une requête va coûter avant de l'envoyer, gardez les pages de tarification des fournisseurs dans vos favoris, et internalisez une règle qui fait économiser de l'argent réel : n'utilisez pas le modèle le plus gros et le plus cher pour des tâches simples.
Un modèle moins cher est souvent plus que suffisant, et la différence de coût à grande échelle est énorme.
Gestion des échecs : les API échouent.
Les limites de débit sont atteintes, les requêtes expirent, le modèle renvoie une sortie malformée.
Gérer cela avec élégance est ce qui rend quelque chose prêt pour la production.
Apprenez à intercepter les erreurs de limite de débit et à réessayer avec un délai croissant entre les tentatives, appelé backoff exponentiel.
La bibliothèque Tenacity en Python fait cela avec un seul décorateur.
Apprenez à valider la sortie du modèle avant de lui faire confiance, et ne laissez jamais une réponse inattendue planter toute votre application.
Injection de prompt, brièvement : c'est le risque de sécurité numéro un dans les applications LLM.
Cela se produit lorsque l'entrée non fiable d'un utilisateur est combinée avec vos instructions, permettant à un utilisateur de remplacer ou de détourner ce que votre système fait.
Vous n'avez pas besoin de devenir un expert en sécurité ce mois-ci, mais vous devez savoir que cela existe avant de livrer quoi que ce soit.
Le guide OWASP à ce sujet est la référence faisant autorité.
Les défenses de base : ne faites pas confiance à la sortie non validée du modèle pour prendre des actions conséquentes automatiquement, et donnez à vos outils le moins d'accès nécessaire pour faire leur travail.
Jalon du Mois 2
À la fin du mois, vous devriez être capable d'écrire des prompts qui produisent une sortie fiable pour une tâche donnée, d'obtenir du JSON structuré d'un modèle avec Pydantic et Instructor, de configurer l'appel d'outils pour qu'un modèle puisse exécuter vos fonctions Python, de diffuser une réponse en temps réel, de gérer l'historique des conversations multi-tours, d'estimer le coût en tokens d'une requête avant de l'envoyer, de gérer les erreurs d'API et les mauvaises sorties sans planter, et d'expliquer ce qu'est l'injection de prompt.
C'est un ensemble de compétences réel et employable en soi.
De nombreuses fonctionnalités d'IA payantes en production font exactement cela et rien de plus.
Mais le mois prochain est celui où vous construisez la chose qui vous fait réellement embaucher.
Mois 3 : RAG et agents, les compétences qui vous font embaucher
Votre objectif ce mois-ci : construire des systèmes qui permettent aux modèles de répondre à partir de vos documents au lieu de seulement leurs données d'entraînement, et construire des systèmes qui effectuent plusieurs étapes par eux-mêmes.
Ces deux compétences, la recherche (retrieval) et les agents, sont les capacités pratiques les plus demandées dans l'ingénierie de l'IA en ce moment.
Presque tous les cas d'utilisation réels en entreprise, des bots de support aux outils de connaissance internes en passant par l'analyse de documents, sont construits sur elles.
J'ai compressé ce que beaucoup de feuilles de route étalent sur deux mois en un seul, parce que vous n'avez pas besoin de maîtriser toutes les variations avancées pour être employable.
Vous devez construire un système de recherche solide et un agent solide, comprendre pourquoi chaque pièce est là, et être capable de les déboguer quand ils cassent.
C'est la barre. Atteignons-la.
RAG, en termes simples d'abord
RAG signifie génération augmentée de recherche (retrieval-augmented generation).
Enlevez le jargon et c'est simple : vous donnez au modèle une bibliothèque dans laquelle chercher des informations, afin qu'il n'ait pas besoin de tout mémoriser, et afin qu'il puisse répondre à des questions sur vos documents spécifiques.
Le flux est : vous prenez vos documents, vous les divisez en morceaux, vous convertissez chaque morceau en une liste de nombres qui capture son sens, et vous les stockez.
Lorsqu'un utilisateur pose une question, vous convertissez sa question en nombres de la même manière, vous trouvez les morceaux dont les nombres sont les plus proches, et vous transmettez ces morceaux au modèle avec la question.
Le modèle répond en utilisant ce que vous lui avez donné. C'est ça, le RAG. Tout le reste est un raffinement.
Construisons les pièces.
Embeddings
Un embedding est un morceau de texte transformé en une longue liste de nombres qui représente sa signification.
La propriété utile : les textes qui signifient des choses similaires se retrouvent avec des nombres similaires, proches les uns des autres dans cet espace numérique.
Cette proximité est ce qui rend possible la recherche par le sens, qui est le moteur du RAG.
Mon choix pour construire l'intuition : l'introduction intuitive du blog Stack Overflow aux embeddings de texte, qui se concentre sur le modèle mental plutôt que sur les mathématiques, plus le guide des embeddings d'OpenAI lorsque vous êtes prêt à les générer en code.
Concentrez-vous sur la compréhension de ce qu'est un vecteur conceptuellement, pourquoi un texte similaire produit des vecteurs similaires, et approximativement comment mesurer la distance entre deux d'entre eux.
Vous n'avez pas besoin des mathématiques derrière la façon dont les embeddings sont produits. Vous devez savoir comment les utiliser.
Une petite construction qui enseigne cela complètement : prenez 20 phrases sur des sujets connexes, transformez chacune en un embedding, et écrivez une petite fonction qui, étant donné une nouvelle phrase, retourne les trois plus similaires de votre ensemble.
C'est le RAG en miniature. Une fois que vous avez construit cela, la version complète est simplement la même idée à plus grande échelle.
Découpage (Chunking)
Vos documents sont trop volumineux pour être intégrés en entier, vous les divisez donc en morceaux avant de les intégrer.
La façon dont vous découpez contrôle directement la qualité avec laquelle votre système trouve les bonnes informations.
Même une configuration de recherche parfaite échoue si les morceaux sous-jacents sont mauvais.
Mon choix : commencez avec le RecursiveCharacterTextSplitter de LangChain, avec une taille de morceau d'environ 500 caractères et un chevauchement d'environ 50.
Ce chevauchement est important, car il vous évite de perdre du sens à la frontière où un morceau se termine et le suivant commence.
C'est la valeur par défaut raisonnable qui vous donne une base de travail fonctionnelle.
Le compromis fondamental à garder en tête : des morceaux trop gros perdent en précision, des morceaux trop petits perdent le contexte.
Commencez avec la valeur par défaut, puis ajustez en fonction de ce que votre recherche fait réellement de travers.
Bases de données vectorielles
Une fois que vous avez des embeddings, vous avez besoin d'un endroit pour les stocker et les rechercher rapidement. C'est ce que fait une base de données vectorielle.
Mon choix pour apprendre : Chroma. Elle fonctionne localement sans infrastructure à configurer, ce qui est exactement ce que vous voulez pendant que vous apprenez.
Vous n'avez pas encore besoin d'échelle cloud gérée, et l'ajouter tôt vous donne juste plus de choses à configurer et à casser.
Chroma vous permet de vous concentrer sur les concepts.
Trouvez-la sur docs.trychroma.com.
Apprenez à créer une collection, insérer des embeddings avec des métadonnées comme la source et la section, interroger par similarité pour obtenir les meilleures correspondances, et filtrer par métadonnées lors de l'interrogation.
Vous n'avez pas besoin de comprendre les algorithmes d'indexation en dessous. Vous devez les utiliser.
Lorsque vous aurez finalement besoin d'une échelle de production, pgvector est la prochaine étape naturelle si votre application utilise déjà une base de données Postgres, et il existe des options gérées lorsque vous voulez que quelqu'un d'autre l'exécute.
Mais c'est une préoccupation du Mois 4 ou du travail. Pour l'instant, Chroma, localement, suffit.
Rendre la recherche réellement bonne
La recherche de similarité de base vous donne une démo.
Quelques raffinements vous donnent quelque chose qui fonctionne de manière fiable, et connaître ceux-ci est ce qui sépare les personnes qui ont copié un tutoriel des personnes qui comprennent le système.
Filtrage par métadonnées : étiquetez chaque morceau avec des informations utiles lorsque vous le stockez, comme le fichier source, la date, la section ou la catégorie.
Ensuite, filtrez sur ceux-ci lors de l'interrogation. C'est la différence entre un jouet et un système où un utilisateur peut demander « montre-moi seulement les résultats du rapport Q4 » et les obtenir réellement.
Reclassement (Reranking) : votre première recherche est rapide mais approximative.
Un reclassement prend les premiers résultats et les re-note pour une pertinence réelle par rapport à la question, ce qui améliore sensiblement la qualité pour un petit coût en vitesse.
Le modèle est : recherchez un large ensemble rapidement, puis re-classez pour obtenir les meilleurs. La documentation de reclassement de Cohere est l'endroit le plus propre pour apprendre cela, et c'est souvent une ligne à ajouter.
Déboguer la recherche, parce que la plupart des échecs RAG sont des échecs de recherche, pas des échecs de modèle.
Lorsque votre système donne une mauvaise réponse, le modèle n'est généralement pas le problème.
La recherche lui a transmis les mauvais morceaux.
Apprenez les modes d'échec courants : la question et le morceau pertinent ne correspondent pas dans l'espace numérique même si l'information est là (réparable en réécrivant la requête), l'information pertinente est répartie sur deux morceaux (réparable avec plus de chevauchement), ou le bon morceau existe mais n'a pas fait partie des meilleurs résultats (réparable en recherchant plus, puis en reclassant).
Lorsqu'une réponse est fausse, vérifiez ce qui a été récupéré avant de blâmer le modèle. Cette seule habitude vous fera économiser une énorme frustration.
Ancrage (Grounding) et citations : un bon système RAG ne se contente pas de répondre, il indique d'où vient la réponse, ce qui renforce la confiance et rend le débogage beaucoup plus facile.
Transmettez les informations de source pour chaque morceau dans votre prompt, et demandez au modèle de le citer.
Voici votre troisième artefact, le prompt d'ancrage qui maintient un système RAG honnête.
C'est celui que je mettrais en favori par-dessus tous les autres, car c'est la différence entre un système qui invente des choses et un système auquel vous pouvez faire confiance.
Prompt : Réponse RAG ancrée
(Cadre : Ancrage FAG, par AI Guides)
1Votre mission : répondre à la question de l'utilisateur en utilisant uniquement le contexte fourni.23Ce qu'il faut faire :4- Lisez les morceaux de contexte ci-dessous. Chacun a une étiquette de source.5- Répondez à la question en utilisant uniquement les informations trouvées dans le contexte.6- Après chaque affirmation, citez l'étiquette de source dont elle provient, comme [source : nom_fichier, p.3].7- Si le contexte ne contient pas la réponse, dites exactement :8 « Je n'ai pas assez d'informations dans les documents fournis pour répondre à cela. »910Règles :11- N'utilisez jamais de connaissances provenant de l'extérieur du contexte fourni.12- Ne devinez jamais. Ne comblez jamais les lacunes avec ce qui semble plausible.13- Si le contexte répond partiellement à la question, répondez à cette partie et dites14 clairement ce qui manque.1516Contexte :17[COLLEZ LES MORCEAUX RÉCUPÉRÉS AVEC LEURS ÉTIQUETTES DE SOURCE ICI]1819Question :20[QUESTION DE L'UTILISATEUR ICI]
Cette instruction « dites exactement ceci quand vous ne savez pas » fait un travail lourd. C'est le moyen le plus efficace de réduire les hallucinations dans un système de recherche, car cela donne au modèle un moyen approuvé d'admettre son ignorance au lieu d'inventer une réponse pour paraître utile.
Votre construction RAG
Utilisez un framework pour relier le tout plutôt que de construire chaque pièce à partir de zéro.
Mon choix pour un premier système RAG est LlamaIndex, qui est construit en priorité pour la recherche et vous donne un pipeline fonctionnel avec une courte quantité de code.
LangChain est l'autre option majeure et brille davantage pour le travail d'agent multi-étapes à venir, vous le rencontrerez donc dans un instant.
Votre objectif de construction, et c'est un véritable projet de portfolio : une application « discutez avec vos documents ».
Ingérez 10 à 20 PDF ou fichiers texte, vos propres notes ou un ensemble de documents produit fonctionnent bien, construisez quelque chose qui prend une question, récupère les morceaux les plus pertinents avec reclassement, et retourne une réponse citée.
Mettez-y une interface simple.
C'est le projet qui fait que les recruteurs vous prennent au sérieux, car c'est exactement le genre de chose que les entreprises paient pour faire construire en ce moment.
Agents
À la moitié du mois, passez aux agents.
Un agent semble magique et est vraiment simple une fois que vous le voyez : c'est une boucle où le modèle décide répétitivement de la prochaine étape, la prend en utilisant un outil, regarde le résultat, et décide à nouveau, jusqu'à ce que la tâche soit terminée.
Le modèle mental : un agent est une boucle while avec un modèle prenant les décisions de branchement.
La réflexion se produit dans le prompt. Le branchement est le modèle choisissant quel outil utiliser. L'action est votre code exécutant cet outil.
Tout le reste est de la plomberie. Une fois que cela clique, même les frameworks d'agents compliqués deviennent lisibles.
Mon choix, et je lirais ceci avant d'écrire une seule ligne de code d'agent : « Building Effective Agents » d'Anthropic.
C'est l'écrit le plus clair sur la façon dont les agents fonctionnent en pratique, de l'équipe qui construit les modèles.
Associez-le à un cours pratique sur un framework lorsque vous êtes prêt à construire, comme l'introduction à LangGraph, qui est le framework le plus utilisé pour orchestrer les agents.
Sur quoi se concentrer : la boucle de perception, décision, action, observation, et comment elle sait quand s'arrêter.
Ce qui se passe lorsqu'un appel d'outil échoue à l'intérieur de la boucle. Comment écrire des descriptions d'outils que le modèle peut réellement utiliser, car un outil décrit de manière vague est appelé de manière incorrecte ou ignoré.
Et la gestion de l'état, qui est la mémoire partagée qui circule à travers l'agent pendant qu'il travaille.
L'exercice le plus précieux de ce mois : construisez un petit agent à partir de zéro sans aucun framework, en utilisant uniquement l'API du modèle directement.
Donnez-lui trois outils, un objectif et une boucle. Cela vous apprend ce que les frameworks cachent, et cela donne un sens à chaque framework que vous touchez par la suite.
Faites cela avant de toucher à LangGraph.
Quand ne pas utiliser un agent
C'est l'une des compétences les plus négligées dans le domaine, et la connaître vous marque comme quelqu'un qui a du jugement plutôt que quelqu'un qui court après la nouveauté.
Les agents sont excitants, et ils sont aussi plus lents, plus chers, moins prévisibles et plus difficiles à déboguer que les approches plus simples.
Rechercher la chose la plus simple qui fonctionne est un signe que vous savez ce que vous faites.
Le cadre de décision, à mémoriser : utilisez un seul appel de modèle si la tâche tient dans un seul prompt avec le bon contexte.
Utilisez un workflow fixe, une chaîne d'étapes que vous définissez, si les étapes sont prévisibles.
Utilisez un agent uniquement lorsque le nombre d'étapes est véritablement imprévisible et nécessite que le modèle décide dynamiquement.
Une chaîne de trois appels fixes sera toujours plus rapide, moins chère et plus facile à déboguer qu'un agent qui pourrait faire trois appels. Réservez les agents pour les tâches véritablement ouvertes.
Entre un seul appel et un agent complet, il existe un vaste terrain d'entente productif : les workflows.
Le chaînage, où la sortie d'un appel alimente le suivant.
Le routage, où vous classifiez l'entrée et l'envoyez à un gestionnaire spécialisé.
La parallélisation, où vous exécutez plusieurs appels à la fois et les combinez.
La plupart des problèmes réels sont mieux résolus avec un workflow, pas un agent, et l'article d'Anthropic sur les agents couvre bien ces modèles.
Évaluations (Evals), brièvement mais sérieusement
Vous devez savoir si votre système fonctionne réellement, pas seulement s'il a fonctionné sur les deux exemples que vous avez testés à la main.
C'est à cela que servent les évaluations. Construisez un petit ensemble de 20 à 30 entrées représentatives avec des sorties attendues ou une grille de notation, et exécutez votre système contre toutes chaque fois que vous modifiez un prompt, changez de modèle ou ajustez votre recherche.
Des outils comme DeepEval pour un usage général et Ragas pour le RAG spécifiquement rendent cela gérable.
L'état d'esprit qui compte plus que l'outil : chaque changement de prompt ou de modèle que vous faites sans exécuter d'évaluations est un pari.
Les personnes qui livrent une IA fiable exécutent des évaluations constamment, et commencer cette habitude maintenant, même à petite échelle, vous place en avance sur beaucoup de personnes déjà dans le domaine.
Jalon du Mois 3
À la fin du mois, vous devriez être capable d'expliquer ce qu'est un embedding et pourquoi un texte similaire produit des vecteurs similaires, de découper un document de manière sensée, de stocker et d'interroger des embeddings dans une base de données vectorielle avec filtrage par métadonnées, d'ajouter un reclassement pour améliorer les résultats, de déboguer un échec de recherche au lieu de blâmer le modèle, de construire un pipeline RAG complet qui retourne des réponses ancrées et citées, d'implémenter une boucle d'agent à partir de zéro, de décider correctement si une tâche nécessite un seul appel, un workflow ou un agent, et d'exécuter une évaluation de base pour vérifier votre travail.
C'est le noyau employable.
Si les Mois 1 à 3 sont solides, vous pouvez construire les choses pour lesquelles les entreprises embauchent.
Le Mois 4 consiste à le prouver et à être payé.
Mois 4 : Livrez-le, montrez-le, faites-vous embaucher
Votre objectif ce mois-ci : prenez tout ce que vous avez construit et rendez-le réel, puis transformez-le en un emploi ou un travail rémunéré.
C'est là que la plupart des gens calent.
Ils peuvent construire une démo mais ne peuvent pas livrer quelque chose qui survit à une utilisation réelle, et ils ne peuvent pas convertir leurs compétences en revenus.
Ce mois-ci résout les deux. Il est plus court sur les nouveaux concepts et plus lourd sur l'action, car à ce stade, l'action est ce qui compte.
Assez de déploiement pour être dangereux
Vous n'avez pas besoin de devenir un expert en infrastructure.
Vous devez être capable de mettre une application d'IA fonctionnelle quelque part où de vraies personnes peuvent l'utiliser, sans qu'elle ne tombe en panne ou ne vous ruine.
Les connaissances minimales viables : apprenez suffisamment de Docker pour empaqueter votre application afin qu'elle fonctionne partout de la même manière, ce qui tue le problème « ça marche sur ma machine ».
Apprenez à déployer ce conteneur quelque part.
Et apprenez les bases des coûts et de la fiabilité qui empêchent un bug de devenir un désastre : définissez des limites de dépenses strictes sur vos comptes API, ajoutez une mise en cache pour ne pas payer deux fois la même requête, et ajoutez une limitation de débit pour qu'un seul utilisateur ne puisse pas faire grimper votre facture.
Le guide officiel de démarrage de Docker couvre l'empaquetage.
Pour le côté coût spécifique à l'IA, les mouvements de base sont la mise en cache des requêtes identiques, l'utilisation de modèles moins chers là où ils sont suffisamment bons, et la définition d'un plafond de dépenses mensuelles strict afin qu'une boucle incontrôlée ne puisse pas vous coûter 500 $ du jour au lendemain.
Vous voulez également une observabilité de base, qui est un mot sophistiqué pour pouvoir voir ce que votre application fait.
Les applications LLM ont un problème spécifique : le modèle peut retourner une réponse parfaitement réussie qui est également inutile ou fausse, et la surveillance normale ne détectera pas cela.
Un outil comme Langfuse trace chaque appel de modèle, vous montrant le prompt, la réponse, le coût en tokens et la latence, ce qui rend le débogage et le contrôle des coûts beaucoup plus faciles.
Configurez cela sur un projet pour comprendre le modèle.
N'investissez pas trop ici.
Une application, déployée correctement, avec des contrôles de coûts et un traçage de base, vous apprend tout ce dont vous avez besoin et vous donne quelque chose de réel à montrer.
La profondeur du déploiement peut venir sur le tas.
La partie que toutes les autres feuilles de route sautent : transformer les projets en emploi.
Vous avez construit trois vrais projets. Maintenant, faites-les travailler pour vous, car un excellent projet que personne ne voit ne fait rien pour votre carrière.
Votre portfolio est composé de trois projets déployés, chacun avec un README qui fait un travail réel.
Et voici la manœuvre que presque personne ne fait, celle qui vous distinguera : dans chaque README, incluez une section sur ce qui a mal tourné et ce que vous feriez différemment.
La plupart des portfolios prétendent que tout a fonctionné parfaitement, ce qui est perçu comme malhonnête ou superficiel.
Un README qui dit « voici où ma première approche a échoué, voici ce que j'ai appris, voici comment je l'ai corrigé » signale exactement le jugement que les employeurs ont dit qu'ils recherchaient désormais.
C'est l'avantage du reconverti de l'introduction, rendu visible.
Personne ne s'attend à ce qu'un reconverti ait un projet parfait. Ils sont impressionnés par quelqu'un qui comprend clairement son propre travail suffisamment profondément pour le critiquer.
Structurez chaque README comme ceci : le problème que le projet résout, qui l'utiliserait, l'approche que vous avez adoptée et pourquoi, ce qui a mal tourné et ce que vous avez appris, et comment l'exécuter.
Cinq sections.
C'est un meilleur portfolio que la plupart des gens avec un diplôme en informatique.
Le mouvement pour le CV et le profil : vous n'avez pas besoin de prétendre avoir des années d'expérience.
Vous avez besoin d'une ligne claire qui dit ce que vous pouvez faire.
Quelque chose comme « Je construis des applications LLM de production : systèmes RAG, agents et intégrations API. En voici trois que j'ai livrés. »
Ensuite, liez les projets. Votre carrière existante est un atout, pas quelque chose à cacher.
« Ancien [votre domaine] qui construit maintenant des systèmes d'IA » est une histoire plus forte que « développeur junior », car elle vient avec la connaissance du domaine et le jugement qu'un junior pur manque.
Si vous venez du secteur financier, vous comprenez les problèmes financiers qu'une IA pourrait résoudre.
Si vous venez du secteur de la santé, pareil. Exploitez cette expertise.
Construire en public comme votre pipeline : tout au long de ce mois, continuez à publier ce que vous construisez et ce que vous apprenez.
Les meilleures opportunités que j'ai vues sont venues à des personnes visibles, pas à celles qui ont postulé discrètement à 500 offres.
Rédigez vos projets. Partagez l'erreur que vous avez corrigée. L'effet cumulatif est réel, et maintenant vous avez du vrai travail à partager, c'est donc plus facile qu'au Mois 1.
Choisissez une direction
Au Mois 4, vous pouvez orienter vos compétences vers ce qui correspond à vos objectifs. Trois directions, choisissez-en une pour approfondir plutôt que de vous éparpiller.
La voie d'ingénieur produit IA, la meilleure si vous voulez un emploi en startup rapidement : vous construisez des produits alimentés par l'IA que de vrais utilisateurs touchent.
Vous avez déjà la plupart de ces compétences grâce aux Mois 1 à 3.
Approfondissez la création d'applications complètes et soignées, et le côté produit, c'est-à-dire comment l'application gère les erreurs du modèle, comment elle affiche les états de chargement, comment les utilisateurs donnent leur avis.
Livrez deux ou trois choses que les gens peuvent réellement essayer.
La voie ML appliquée, la meilleure si vous voulez des rôles techniques plus pointus : allez au-delà des appels API vers le fine-tuning, quand fine-tuner par rapport à simplement améliorer le prompt, exécuter des modèles open-source localement avec un outil comme Ollama, et l'optimisation de l'inférence.
Le cadre de décision à retenir : commencez par le prompting, ajoutez de la récupération si le modèle a besoin de vos données spécifiques, et ne faites du fine-tuning que lorsque le prompting et la récupération ne peuvent vraiment pas atteindre la qualité dont vous avez besoin.
Le fine-tuning est souvent utilisé trop tôt.
La voie de l'automatisation IA, la meilleure si vous voulez gagner de l'argent avec des entreprises immédiatement : concentrez-vous sur l'automatisation de flux de travail métier réels, en enchaînant l'IA à travers des outils comme les e-mails, les CRM, les documents et les feuilles de calcul.
Des outils comme n8n pour les flux de travail visuels et LangGraph pour ceux qui sont plus axés sur le code.
Une réalisation vendable ici : un système de qualification de leads qui importe des leads, utilise un modèle pour rechercher et noter chacun, rédige des messages de prospection personnalisés et enregistre tout.
Les entreprises paient de l'argent réel pour exactement cela.
Jalon du Mois 4
À la fin du mois, vous devriez avoir une application IA déployée avec des contrôles de coûts appropriés, trois projets de portfolio chacun avec un README honnête, un pitch clair en une ligne de ce que vous construisez, une trace visible de votre travail en public, et une direction choisie dans laquelle vous approfondissez.
À ce stade, vous n'êtes plus "quelqu'un qui apprend l'IA". Vous êtes quelqu'un qui livre des systèmes d'IA, ce qui est ce que le marché paie.
La partie honnête
Je vous ai dit au début que je n'allais pas vous vendre un fantasme, alors voici la version directe avant les chiffres d'argent.
Quatre mois de travail concentré vous rendent employable à un niveau junior ou prêt à accepter du travail en freelance. Cela ne fait pas de vous un ingénieur senior.
Le niveau senior vient d'années à livrer des choses réelles sous des contraintes réelles, et aucun guide ne peut compresser cela.
Ce que quatre mois vous apportent, c'est la capacité de construire, livrer et déployer des systèmes d'IA qui résolvent des problèmes réels, ce qui est une position véritablement précieuse et véritablement embauchable.
Cela suppose un travail réel, environ 15 à 20 heures par semaine, à construire réellement et pas seulement à regarder.
Si vous ne pouvez y consacrer que 7 heures par semaine, c'est un parcours de 8 mois, et c'est tout à fait acceptable.
Le calendrier s'étire, la destination ne change pas. Ce qui tue les gens, ce n'est pas un rythme lent. C'est l'arrêt.
La constance bat l'intensité ici à chaque fois.
Et le tout repose sur un comportement de la section sur les erreurs : construisez, ne vous contentez pas de regarder.
Chaque mois a un projet. Faites les projets. Une personne qui construit quatre projets approximatifs en quatre mois est embauchable.
Une personne qui regarde quatre mois de tutoriels parfaits ne l'est pas. C'est tout le jeu.
L'argent, avec des sources
Maintenant, les chiffres que vous voulez vraiment, tous actuels et tous sourcés, car des affirmations salariales vagues sont ce qui fait perdre leur crédibilité à ces guides.
En date de juin 2026, Glassdoor estime le salaire moyen d'un ingénieur IA américain à environ 143 500 $, avec une fourchette typique d'environ 115 000 $ au 25e percentile à 181 000 $ au 75e, et les salaires les plus élevés signalés jusqu'à environ 223 000 $.
Les ingénieurs IA seniors gagnent en moyenne environ 285 000 $, avec une fourchette typique d'environ 221 000 $ à 375 000 $, ce qui montre à quel point le saut est important une fois que vous avez une vraie expérience.
Ce sont les chiffres de Glassdoor basés sur les salaires soumis.
Les recruteurs qui placent des personnes dans un travail d'IA de production réel rapportent des salaires de base de niveau intermédiaire se situant entre 155 000 $ et 200 000 $, basés sur des offres signées plutôt que sur des enquêtes, ce qui correspond à la fourchette de Glassdoor et vous donne une deuxième lecture indépendante.
Et le contexte plus large du marché selon le Baromètre 2026 de PwC, que j'ai mentionné en ouverture : les emplois liés aux compétences en IA croissent environ huit fois plus vite que le marché global, une prime salariale de 62 % pour les compétences en IA, et les exigences de diplôme chutent le plus rapidement dans exactement ces rôles.
Ces chiffres ne proviennent pas d'un fil de discussion hype. Ils proviennent d'une analyse de plus d'un milliard d'offres d'emploi.
Les chiffres du freelance et du conseil varient trop pour être cités précisément sans vous induire en erreur, donc je dirai seulement ceci : les tarifs pour la mise en œuvre de RAG, la création d'agents et l'intégration de LLM sont élevés, et un reconverti avec trois projets solides déployés et un pitch clair peut commencer à facturer ce travail bien avant de décrocher un poste à temps plein.
Les projets sont la preuve. Construisez-les et les options de revenus s'ouvrent.
Commencez cette semaine
Voici ce que je ferais réellement, aujourd'hui, si j'étais vous.
Choisissez le projet Python du Mois 1, le petit outil en ligne de commande. Ouvrez un éditeur de code.
Commencez le premier ensemble de problèmes de CS50P. Configurez le prompt du partenaire d'apprentissage pour que l'IA vous guide à travers les parties frustrantes.
Créez un dépôt GitHub et mettez-y votre premier fichier moche. C'est toute la première semaine.
N'attendez pas de vous sentir prêt, car la préparation vient après avoir commencé, pas avant.
Ne planifiez pas les quatre mois dans les moindres détails avant d'écrire une ligne de code, car le plan est déjà là et la planification n'est qu'une manière confortable d'éviter de commencer.
Le fossé entre apprendre et construire est l'endroit où les gens perdent un an. Comblez-le cette semaine.
Quatre mois de travail réel changent véritablement ce qui est possible pour vous.
La porte est plus ouverte qu'elle ne l'a jamais été, la barrière des diplômes tombe, et le marché paie plus pour ces compétences que pour presque tout autre chose dans la tech.
Vous avez le guide. La seule variable qui reste est de savoir si vous construisez.
Sauvegardez ceci et revenez-y chaque mois au fur et à mesure. Je le mettrai à jour au fur et à mesure que les outils et les chiffres changeront.
Suivez @free_ai_guides pour les mises à jour ❤️
