Parcours d’apprentissage AI Engineering from Scratch : comment suivre 523 leçons d’ingénierie de l’IA ? De Python aux LLM, au RAG et aux projets pratiques, quelle configuration faut-il ?

Le meilleur choix consiste à suivre AI Engineering from Scratch à partir du projet visé et des acquis déjà maîtrisés, plutôt qu’à traiter les 523 leçons comme une liste obligatoire. Cette approche convient si le parcours est adapté aux prérequis de chacun et si l’environnement reste local pour les exercices légers, puis distant seulement lorsqu’une expérience précise l’exige.

Les développeurs Python qui veulent passer à l’ingénierie des LLM peuvent sélectionner les étapes utiles à leur objectif.
Les débutants peuvent repérer les bases à consolider avant d’aborder les notions de machine learning et les applications de modèles.
Les ingénieurs qui préparent un portfolio peuvent juger le parcours sur des projets reproductibles, pas sur un taux d’avancement.

Dernière vérification éditoriale : 30 septembre 2026, à partir du dépôt officiel et de ses notes de version, du catalogue du cours et des parcours d’apprentissage publiés par le cours. Le contenu et les dépendances des exercices peuvent évoluer : vérifiez les fichiers du cours correspondant au projet choisi avant d’installer des outils ou de réserver une machine.

Choisir un parcours selon le niveau et le résultat attendu

Le catalogue officiel présente un ensemble étendu de leçons et de projets. Il sert à explorer le contenu, mais ne démontre pas que chaque personne doit suivre chaque élément dans le même ordre. La page consacrée aux parcours d’apprentissage est plus utile pour repérer des chemins selon les acquis et les sujets visés.

Le terme « 523 leçons » décrit l’ampleur du contenu annoncé, pas une durée garantie, un prérequis matériel ou une promesse de compétence professionnelle. Le dépôt officiel permet de contrôler directement le contenu et les projets disponibles ; les notes de version aident à repérer les changements susceptibles de modifier une consigne ou une dépendance.

Avant de commencer, formulez une question plus concrète que « combien de leçons reste-t-il ? » : « quel résultat puis-je produire, expliquer et refaire à la fin de cette étape ? » Un parcours valable doit rapprocher chaque séance d’un livrable, par exemple un programme de classification, une recherche sur des documents ou un agent utilisant un outil avec des limites et des tests.

Profil et objectif	Point de départ conseillé	Vérification avant de poursuivre	Environnement à privilégier
Développeur Python visant une application LLM	Repérer dans le catalogue les sections liées aux modèles, aux applications et aux projets, puis vérifier les prérequis	Expliquer le code, traiter les erreurs et reproduire le résultat sans copier aveuglément l’exemple	Local pour le code et les appels d’API ; distant seulement si l’expérience le nécessite
Débutant en programmation	Suivre les bases indiquées par le parcours officiel, puis tester les notions avec de petits exercices	Écrire et modifier un programme simple, lire une erreur et organiser un environnement de travail	Local, avec un environnement Python isolé
Ingénieur visant un projet RAG	Délimiter un cas de recherche documentaire et repérer les étapes portant sur les modèles, les données et la récupération	Montrer qu’une question retrouve des passages pertinents et que les réponses peuvent être contrôlées	Local pour préparer et tester les données ; ressources distantes selon le modèle retenu
Ingénieur visant un agent ou un déploiement	Relier les thèmes agent, outils et production aux expériences réellement prévues dans le projet	Fournir des tests, des traces d’exécution et une explication des permissions et des échecs	Selon les dépendances du projet ; distant uniquement si les besoins constatés le justifient

Ce tableau est un outil d’orientation, pas une description exhaustive du programme. Les intitulés et dépendances précis doivent être vérifiés dans le catalogue et les fichiers officiels avant de construire l’environnement.

Commencer par les bases uniquement lorsqu’elles sont nécessaires

AI Engineering from Scratch convient-il sans expérience de Python ?

Le parcours peut être exploré par une personne qui débute, mais l’absence de bases en programmation change la manière de l’aborder : il vaut mieux consolider les prérequis signalés dans le chemin officiel que commencer par des exercices LLM dont le code reste opaque. Le tutoriel officiel de Python permet de vérifier les notions de langage à travailler, tandis que les indications du cours déterminent les sujets effectivement nécessaires à ses exercices.

Les mathématiques et le machine learning ne doivent pas être abordés comme une formalité à cocher. Ils deviennent utiles lorsqu’un exercice demande d’interpréter des données, d’évaluer une prédiction ou de comprendre ce que mesure un modèle. Pour vérifier les acquis, un débutant peut écrire un petit programme qui lit des entrées, applique une règle explicite, produit un résultat et gère un cas invalide. L’objectif n’est pas de créer un cours parallèle : il s’agit de déterminer si les instructions et les erreurs courantes sont compréhensibles avant d’ajouter des bibliothèques plus complexes.

Pour le versant apprentissage automatique, les premières pages du guide « Getting Started » de scikit-learn donnent un point de repère concret sur la manière d’utiliser une bibliothèque de machine learning. Cela ne signifie pas que tout lecteur doit maîtriser cette bibliothèque avant de toucher aux LLM. La bonne décision consiste à suivre les prérequis explicitement reliés au module choisi, et non à transformer chaque ressource associée en obligation générale.

Une base de programmation est suffisamment solide pour avancer lorsqu’il est possible de lire une fonction, de modifier une entrée, d’exécuter un script, de repérer où survient une erreur et de décrire ce que le programme renvoie. Si ces tâches restent difficiles, revenir aux contenus fondamentaux est plus efficace que d’accumuler des notebooks dont le fonctionnement n’est pas compris.

Ajuster la révision au niveau déjà acquis

Un développeur Python n’a pas forcément besoin de reprendre toute l’initiation au langage. Il peut parcourir le programme officiel, comparer les thèmes annoncés aux tâches qu’il sait déjà réaliser, puis consacrer une séance de vérification à un exercice proche du travail quotidien : charger des données, appeler une fonction, traiter une exception et expliquer la sortie. Si l’exercice est reproductible sans suivre chaque ligne à l’aveugle, les modules de programmation correspondants peuvent être révisés rapidement ou écartés.

Il ne faut toutefois pas confondre familiarité avec la syntaxe Python et maîtrise de l’ingénierie des applications LLM. Les dépendances, les formats de données, la gestion des erreurs et l’évaluation d’un résultat peuvent exiger de nouvelles habitudes, même pour une personne qui développe depuis longtemps. La révision doit donc porter sur le geste technique manquant, pas sur le titre général d’un module.

Avant d’installer toute la pile technique, choisissez un exercice officiel et lisez son fichier de dépendances ainsi que ses instructions. Si une bibliothèque, un accès distant ou un modèle particulier est requis, consignez-le ; ne déduisez pas les besoins matériels du nombre total de leçons.

Construire un parcours LLM et RAG autour d’un cas vérifiable

Par où commencer pour apprendre les LLM et le RAG ?

Pour une application RAG, le bon départ dépend de ce que le projet doit démontrer. Il faut comprendre le rôle du modèle, préparer les documents, rechercher des passages utiles, transmettre le contexte à l’application puis vérifier les réponses. Le parcours doit couvrir les notions nécessaires à ces opérations, mais il n’est pas utile d’étudier chaque thème de modèle avant d’avoir défini le problème documentaire à résoudre.

La documentation de Transformers sur le RAG fournit une référence technique sur cette approche. Elle ne remplace pas les consignes du cours et ne prouve pas que tous les exercices utilisent les mêmes composants. Elle aide plutôt à distinguer la génération de texte de la récupération de contexte, distinction essentielle lorsqu’un prototype répond de façon convaincante sans retrouver les bons éléments dans les documents.

Un premier projet doit rester assez petit pour permettre d’inspecter ses entrées et ses résultats. Par exemple, un prototype peut traiter un ensemble limité de documents autorisés, retourner les passages récupérés avec la réponse et permettre à une autre personne de vérifier si ces passages appuient effectivement la réponse. Ce test révèle des problèmes de préparation ou de recherche qui resteraient invisibles si l’évaluation se limitait à « le modèle a répondu ».

La progression vers une application plus complexe est justifiée lorsque le prototype permet déjà de répondre à des questions contrôlables, que les échecs sont consignés et que les données sont préparées de façon répétable. À ce stade, il devient pertinent de comparer d’autres stratégies de récupération ou d’étendre les documents. Commencer par une architecture ambitieuse avant d’avoir vérifié ces éléments ajoute des variables sans aider à identifier la cause des erreurs.

Séparer les apprentissages des expériences de modèle

Les exercices de programmation, la préparation des données, les appels à une API et l’exécution locale d’un modèle n’ont pas les mêmes exigences. Le premier groupe peut souvent être étudié sans lancer de grand modèle ; un appel distant dépend plutôt des accès et des instructions de l’exercice ; une expérience locale ou un entraînement doit être évalué d’après les dépendances et les ressources réellement documentées.

Le guide d’installation de PyTorch permet de sélectionner une installation en fonction de la plateforme et de l’usage prévu. Il faut le consulter au moment où un exercice nécessite réellement PyTorch, et non en déduire qu’une machine particulière est indispensable à l’ensemble du cours. De même, les besoins d’un modèle dépendent du modèle et de la tâche choisis ; aucun seuil matériel ne peut être déduit du nombre de leçons.

Pour les exercices qui fonctionnent dans un environnement hébergé, les questions fréquentes officielles de Colaboratory précisent les conditions et limites du service. Cette lecture est importante avant de s’appuyer sur une session distante pour un travail long ou reproductible : l’existence d’un environnement hébergé ne signifie pas que ses ressources, sa disponibilité ou la durée de session conviennent automatiquement à un entraînement ou à un travail de longue durée.

Traiter les agents et la production comme des objectifs distincts

Un agent n’est pas simplement un appel LLM auquel on ajoute une description de rôle. Un projet exploitable doit montrer comment les outils sont sélectionnés, quelles entrées ils reçoivent, ce qui se passe lorsqu’ils échouent et quelles opérations sont interdites. Pour décider quelles parties du programme suivre, rapprochez les thèmes de l’agent, de l’utilisation d’outils et de la production dans le catalogue officiel, puis vérifiez que le projet retenu comprend effectivement ces étapes.

L’ordre d’apprentissage doit suivre les dépendances du projet. Une personne qui vise un prototype peut d’abord se concentrer sur l’appel du modèle et un outil contrôlé. Une personne qui vise une mise en production doit aussi prévoir les tests, les journaux d’exécution, la gestion des secrets et le comportement en cas d’erreur, si ces éléments font partie de son périmètre. Il ne faut pas annoncer que le cours garantit la maîtrise de ces sujets : seuls le programme visible et les fichiers d’exercice permettent de confirmer ce qui est couvert.

L’évaluation doit porter sur des preuves concrètes. Un agent peut être démontré par une exécution reproductible, des tests sur des entrées attendues et inattendues, et une trace permettant de comprendre les décisions et les appels d’outils. Si le projet échoue sans expliquer pourquoi, ou s’il effectue une action non prévue, compléter davantage de leçons ne constitue pas à lui seul une validation.

Le même principe vaut pour les projets créatifs. Dans un flux audio ou vidéo, une démonstration peut présenter l’entrée, les transformations effectuées, la sortie et les limites constatées. Dans un projet de conception, un exemple reproductible et des critères d’évaluation sont plus convaincants qu’une simple capture d’écran. Les choix de données et d’outils doivent rester conformes aux droits et aux règles applicables au projet.

Décider entre environnement local et ressources distantes

La première décision est souvent de rester en local. L’édition de code, les petits exercices Python, l’inspection de données et les tests qui ne lancent pas de modèle volumineux ne justifient pas automatiquement une machine distante. Un environnement virtuel sépare les dépendances du projet de celles des autres programmes ; la documentation Python consacrée à venv décrit ce mécanisme et sa mise en place.

Un environnement distant devient à évaluer lorsque l’exercice officiel exige des ressources ou un accès indisponibles localement, lorsque l’installation locale bloque réellement le travail, ou lorsque l’objectif consiste précisément à reproduire une configuration de déploiement. Avant ce choix, comparez les coûts moins visibles : configuration et transfert des données, authentification, accès réseau, conservation des fichiers et temps passé à diagnostiquer une machine qui ne reproduit pas l’exercice. Si une session hébergée est envisagée, vérifiez également ses limitations dans sa documentation plutôt que de supposer qu’elle conviendra à un entraînement ou à un travail de longue durée.

Pour un environnement de développement à distance, il est utile de distinguer les informations générales sur Zutcloud et son activité des exigences techniques propres à un exercice. Une présentation de service ne suffit pas à établir qu’une machine répond à une dépendance particulière du cours. Pour clarifier les modalités d’accès et les questions pratiques, le centre d’aide de Zutcloud constitue un autre point de référence ; il ne remplace pas la vérification des exigences techniques de l’exercice.

La grille de décision est simple : si l’exercice tourne localement et que le résultat est reproductible, poursuivre en local ; si une dépendance ou une limite identifiée empêche l’expérience, comparer les environnements distants selon cette contrainte précise ; si l’objectif requiert une interface physique, un périphérique particulier ou une charge soutenue, vérifier explicitement que l’option retenue peut répondre à ce besoin. Les informations disponibles ne permettent pas de recommander une configuration, un prix, une région ou une durée de location précise.

Suivre une progression qui produit des preuves de compétence

Les étapes suivantes sont un moyen d’organiser le travail, pas une promesse de durée ou de résultat professionnel. Elles doivent être rapprochées des chemins et des expériences effectivement présents dans la version consultée.

1. Définir le livrable. Formulez une tâche visible : classer des textes, répondre à des questions sur des documents, ou faire exécuter à un agent une opération limitée. Décrivez les entrées attendues et ce qui constituerait un résultat incorrect.
2. Auditer les prérequis. Consultez les apprentissages officiels et l’exercice qui correspond au livrable. Notez les notions de Python, les bibliothèques, les accès et les ressources explicitement demandés.
3. Tester les lacunes avant de suivre le cours en entier. Reproduisez un exercice court, modifiez une entrée et expliquez la sortie. Si une étape reste incomprise, revenez au prérequis concerné plutôt qu’à toutes les leçons précédentes.
4. Construire un prototype vérifiable. Gardez une trace des données, de la configuration et des étapes nécessaires pour relancer le projet. Pour un RAG, examinez les passages retrouvés ; pour un agent, inspectez les appels d’outils et les erreurs.
5. Choisir l’environnement à partir du blocage observé. Commencez par ce qui fonctionne localement. Comparez une option distante uniquement après avoir identifié une limite liée aux dépendances, aux ressources ou au déploiement.
6. Documenter les résultats et leurs limites. Fournissez un exemple d’exécution, des tests et les cas où le système échoue. Une démonstration honnête des limites est plus utile à un portfolio qu’une affirmation générale de performance.
7. Réviser le parcours. Si le projet progresse sans difficulté sur un sujet déjà maîtrisé, réduisez le temps consacré à ce sujet. Si le résultat échoue pour une raison incomprise, choisissez l’étape d’apprentissage qui répond directement à cette lacune.

Un environnement Python isolé rend les expériences plus faciles à reproduire ; la documentation officielle explique comment créer et utiliser venv. Cette séparation ne résout pas les problèmes de ressources ou de dépendances système, mais évite de confondre les bibliothèques d’un projet avec celles d’un autre.

Pour évaluer un portfolio, vérifiez que le projet peut être présenté sans prétendre que sa seule réalisation démontre une expertise complète. Une personne qui consulte le résultat devrait pouvoir comprendre le problème, relancer l’expérience, voir les principaux choix techniques et identifier les limites. La longueur du parcours et le nombre de contenus terminés ne garantissent ni un emploi ni la maîtrise de tous les domaines de l’ingénierie de l’IA.

Le choix d’un Mac distant mérite donc d’être comparé à l’environnement déjà disponible, et non posé comme étape obligatoire de l’apprentissage. Une solution locale peut être plus simple pour les exercices légers ; un environnement distant peut aider lorsqu’un besoin précis est confirmé. En revanche, l’installation et l’accès ajoutent des étapes, les ressources réelles doivent être vérifiées et un poste distant ne remplace pas une configuration adaptée aux charges soutenues ou aux périphériques physiques. Pour décider si les expériences prévues justifient un accès à distance, confrontez les besoins de chaque exercice aux caractéristiques effectivement annoncées avant de retenir une option.