Problème 7027

Je travaille à l'expansion du site web d'AI Shipping Labs (https://aishippinglabs.com/) et je souhaitais migrer sa version actuelle, hébergée sur GitHub Pages, vers AWS. Mon objectif était de remplacer ultérieurement l'architecture Next.js d'origine par une version Django.

Mon plan progressif était le suivant :

1. Migrer le site statique actuel de GitHub Pages vers AWS S3

2. Migrer le DNS vers AWS afin que le domaine soit entièrement géré sur cette plateforme

3. Déployer la nouvelle version Django sur un sous-domaine

4. Une fois la migration fonctionnelle, basculer le domaine principal vers Django

Ainsi, tout serait déjà hébergé sur AWS et la migration finale se ferait sans problème.

La stratégie de migration en elle-même était pertinente, mais les difficultés sont apparues lors de sa mise en œuvre.

J'étais trop dépendant de mon agent Claude Code, qui a accidentellement effacé toute l'infrastructure de production de la plateforme de gestion de cours DataTalks.Club (https://courses.datatalks.club/), qui stockait les données de deux ans et demi de soumissions : devoirs, projets, classements, pour tous les cours dispensés via la plateforme.

Pire encore, tous les instantanés automatiques ont également été supprimés. J'ai dû passer à l'assistance AWS Business, ce qui m'a coûté 10 % de plus pour une assistance plus rapide. Heureusement, ils m'ont aidé à restaurer la base de données, et la récupération complète a pris environ 24 heures.

Dans cet article, je vais vous expliquer comment cela s'est produit et les mesures que j'ai prises pour éviter que cela ne se reproduise.

Chronologie de l'incident

---

Jeudi 26 février

• Vers 22h00 : J'ai commencé le déploiement des modifications du site web avec Terraform, mais j'ai oublié d'utiliser le fichier d'état, car il se trouvait sur mon ancien ordinateur.

• Vers 23h00 : Une commande d'approbation automatique Terraform a effacé par inadvertance toute l'infrastructure de production, y compris Amazon Relational Database Service (RDS). J'ai découvert par la suite que tous les snapshots avaient également été supprimés, ce qui m'a incité à ouvrir un ticket auprès du support AWS.

Ven. 27 févr.

• Vers 00h00 : Passage au support AWS Business pour bénéficier de temps de réponse plus rapides.

• Vers 00h30 : Le support AWS a confirmé l'existence d'un snapshot de leur côté.

• Entre 1h00 et 2h00 : Appel téléphonique avec le support AWS, qui a transmis le problème à leur équipe interne pour la restauration.

• Dans la journée : Mise en œuvre de mesures préventives, notamment la configuration d'une fonction Lambda de sauvegarde, l'activation de la protection contre la suppression, la création de sauvegardes S3 et le déplacement de l'état Terraform vers S3.

• Vers 22h00 : La base de données a été entièrement restaurée, contenant à elle seule 1 943 200 lignes dans la table courses_answer. La plateforme a été remise en ligne.

Comment le problème est survenu

---

Réutilisation d'une configuration Terraform existante

J'utilisais déjà Terraform pour gérer l'infrastructure de production d'un autre projet : une plateforme de gestion de cours pour les Zoomcamps de DataTalks.Club (https://courses.datatalks.club/). Au lieu de créer une configuration distincte pour AI Shipping Labs, je l'ai intégrée à la configuration existante pour économiser un peu d'argent.

Claude essayait de me dissuader, me disant de conserver une configuration séparée, mais je voulais économiser car j'ai une infrastructure où tout est hébergé dans un cloud privé virtuel (VPC), avec toutes les ressources sur un réseau privé, un véritable bastion pour l'hébergement des machines.

Les économies ne sont pas si importantes, peut-être 5 à 10 $ par mois, mais je me suis dit : « Pourquoi ai-je besoin d'un autre VPC ? » et j'ai donc configuré Terraform pour tout y gérer. Cela a accru la complexité et les risques, car les modifications apportées à ce site étaient désormais mêlées à celles apportées à l'autre infrastructure.

Premier signe d'alerte

Au lieu de suivre le plan manuellement, j'ai laissé Claude Code exécuter terraform plan puis terraform apply. Mon premier indice d'un problème est apparu lorsque j'ai vu une longue liste de ressources créées. C'était incompréhensible : l'infrastructure existait déjà. Nous ne construisions pas un nouvel environnement.

J'ai interrompu Claude et lui ai demandé : « Pourquoi créons-nous autant de ressources ? » La réponse de l'agent était à la fois simple et inquiétante : Terraform pensait qu'aucune infrastructure n'existait.

Mais pourquoi ? J'avais récemment changé d'ordinateur et je n'avais pas migré Terraform. Lorsque j'ai exécuté terraform plan, il a supposé qu'aucune infrastructure n'était présente et que nous partions de zéro.

J'ai rapidement annulé terraform apply, mais certaines ressources avaient déjà été créées.

Analyse et suppression des ressources dupliquées via l'interface de ligne de commande AWS

L'étape suivante consistait à évaluer les ressources créées. J'ai demandé à Claude d'analyser l'environnement à l'aide de l'interface de ligne de commande AWS (AWS CLI) afin d'identifier les ressources nouvellement créées et celles faisant partie de la production. Je souhaitais supprimer uniquement les doublons nouvellement créés, en laissant l'infrastructure existante intacte.

L'assistant a indiqué avoir identifié les ressources dupliquées à l'aide de l'AWS CLI et être en train de les supprimer. Cela semblait correct.

Pendant ce nettoyage, je suis allé sur mon ancien ordinateur, j'ai archivé le dossier Terraform, y compris le fichier d'état, et je l'ai transféré sur la nouvelle machine. Pensant que le nettoyage était terminé, j'ai indiqué l'archive Terraform à l'agent afin qu'il puisse l'utiliser pour comparer les ressources nouvellement créées avec celles archivées.

Suppression avec terraform destroy

L'agent a continué à supprimer des fichiers et, à un moment donné, a affiché le message suivant : « Impossible. Je vais exécuter terraform destroy. Étant donné que les ressources ont été créées via Terraform, les supprimer via Terraform serait plus propre et plus simple que via l'AWS CLI. »

Cela semblait logique : si Terraform a créé les ressources, Terraform devrait les supprimer. Je n'ai donc pas empêché l'agent d'exécuter terraform destroy. La commande s'est terminée avec succès. À ce moment-là, je pensais encore que nous ne supprimions que les ressources nouvellement créées.

J'ai ensuite vérifié la plateforme de gestion des cours DataTalks.Club Zoomcamps, et elle était hors service. Je me suis demandé ce qui se passait et j'ai ouvert la console AWS pour enquêter.

La base de données, le VPC, le cluster ECS, les équilibreurs de charge et l'hôte bastion avaient disparu. Toute l'infrastructure de production avait été détruite.

[

](https://substackcdn.com/image/fetch/$s_!ropw!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcc7921dd-b81d-453a-b832-7c8670a9fbeb_1600x880.jpeg)

Liste complète de l'infrastructure de production détruite : VPC, RDS, cluster ECS, équilibreurs de charge, hôte bastion

Lorsque j'ai demandé à Claude où se trouvait la base de données, sa réponse a été sans équivoque : elle avait été supprimée.

Ce qui s'est réellement passé

En réalité, je n'ai pas remarqué que Claude décompressait mon archive Terraform. Celle-ci a remplacé mon fichier d'état actuel par une version plus ancienne contenant toutes les informations relatives à la plateforme de gestion de cours DataTalks.Club.

Lorsque Claude a exécuté terraform destroy, il a effacé bien plus que les simples doublons temporaires. En réalité, il a détruit l'infrastructure sous-jacente à la plateforme de cours, et non le fichier d'état créé.

Trouver une solution

1. Recherche de sauvegardes

Après avoir constaté la disparition de l'infrastructure de production, j'ai cherché des sauvegardes. Des sauvegardes quotidiennes étaient censées être effectuées.

Il était environ 23 h, et je savais qu'un instantané était créé chaque nuit à 2 h. Je me suis rendu sur la console RDS et j'ai vérifié la disponibilité des instantanés, mais aucun n'était visible. J'ai revérifié la console, sans succès.

Événements RDS du jeudi. La sauvegarde a été créée à 0 h 24 et était visible dans la section Événements de la console AWS, mais la sauvegarde elle-même avait disparu.

Ensuite, j'ai ouvert la section Événements RDS et j'ai constaté qu'une sauvegarde avait bien été créée à 2 h, comme prévu. L'événement était listé, mais lorsque j'ai cliqué dessus, rien ne s'est ouvert et l'instantané était inaccessible.

À ce stade, j'ignorais si la sauvegarde avait été supprimée ou si elle était simplement invisible.

2. Contact avec le support AWS

Vers minuit, j'ai ouvert un ticket de support concernant une base de données supprimée et des sauvegardes manquantes. J'ai contacté mon interlocuteur AWS, mais je ne m'attendais pas à une réponse aussi tardive.

N'ayant pas de nouvelles, j'ai constaté que le support Business offrait un délai de réponse d'une heure pour les incidents de production. J'ai donc opté pour la formule supérieure, ce qui a augmenté mes coûts cloud d'environ 10 %.

J'ai ensuite créé un autre ticket avec tous les détails nécessaires. Le support m'a répondu en 40 minutes environ.

3. Constatations du support AWS

Le support AWS a confirmé la suppression de ma base de données et de tous les snapshots, ce à quoi je ne m'attendais pas. La requête API indiquait clairement à AWS de tout supprimer.

Réponse du support AWS confirmant la suppression du cluster et la découverte d'un snapshot disponible

Première réponse du support AWS : ils ont confirmé la suppression et trouvé un snapshot invisible dans ma console.

Ils ont trouvé un snapshot de leur côté que je ne pouvais pas voir dans ma console. Après avoir signalé ce problème, ils m'ont proposé de faire un appel.

3. Appel avec AWS

Nous avons participé à un appel et avons examiné la situation ensemble.

Ils ont tenté des étapes de récupération de leur côté. Au bout d'un moment, l'ingénieur support a indiqué qu'il devait faire remonter le problème en interne. Nous sommes restés en ligne pendant leur enquête.

Alors que la production était déjà hors service, j'ai commencé à reconstruire d'autres parties de l'infrastructure avec Terraform. Cela a été relativement rapide. J'en ai également profité pour simplifier certaines choses, comme la consolidation de plusieurs équilibreurs de charge en un seul.

J'ai créé une nouvelle instance de base de données vide en prévision d'une éventuelle restauration.

L'appel a duré entre 40 et 60 minutes. Finalement, ils ont indiqué avoir besoin de plus de temps et qu'ils me recontacteraient une fois la situation clarifiée.

4. 24 heures plus tard

Exactement 24 heures après la suppression de la base de données, AWS a restauré l'instantané.

J'ai reçu un e-mail confirmant que la restauration du snapshot était terminée et prête à l'emploi :

E-mail du support AWS confirmant la fin de la restauration du snapshot

E-mail du support AWS confirmant la restauration et la disponibilité du snapshot

Le snapshot, auparavant invisible, est désormais visible dans la console.

Snapshot restauré

5. Restauration de la base de données

J'ai recréé la base de données à partir du snapshot restauré via Terraform.

À ce stade, j'ai modifié ma façon d'utiliser Terraform grâce à Claude Code. Toutes les permissions sont désactivées. Aucune exécution automatique. Aucune écriture de fichier.

Le processus est maintenant simple :

Générer un plan

Le vérifier manuellement

Exécuter les commandes manuellement

Après la restauration de la base de données, j'ai vérifié les données. La table courses_answer contenait 1 943 200 lignes :

Terminal affichant la requête PostgreSQL avec 1 943 200 lignes restaurées dans la table courses_answer

Les données sont de retour : 1 943 200 lignes dans la table courses_answer La plateforme de gestion des cours est de nouveau en ligne. Tous les devoirs étaient visibles.

Tableau de bord du cours Data Engineering Zoomcamp 2026 affichant tous les devoirs.

La dernière étape consistait à configurer les sauvegardes sur la nouvelle instance de base de données et à supprimer soigneusement la base de données temporaire vide créée lors de l'incident, en veillant à ne pas les confondre.

Mesures prises pour éviter que cela ne se reproduise :

En attendant qu'AWS résolve le problème de snapshots, j'ai mis en place des mesures de protection. Je ne voulais pas qu'une simple commande de destruction puisse à nouveau tout effacer.

Voici les modifications apportées :

1. Sauvegardes indépendantes de l'état Terraform :

J'ai créé des sauvegardes non gérées par Terraform.

Je ne m'attendais pas à ce que les snapshots disparaissent avec la base de données. Pour éviter ce risque, j'ai veillé à disposer de sauvegardes indépendantes du cycle de vie Terraform.

J'ai également ajouté des sauvegardes sur S3. Celles-ci sont stockées séparément de la base de données et ne sont pas liées à l'état de l'infrastructure.

2. Test de restauration quotidien avec Lambda et Step Functions :

J'ai créé un flux de travail de sauvegarde automatisé.

Chaque nuit à 2 h du matin, AWS crée une sauvegarde automatisée régulière. Vers 3 h du matin, une fonction Lambda s'active et crée une nouvelle instance de base de données à partir de cette sauvegarde. Je dispose ainsi chaque jour d'une copie à jour de mon environnement de production. L'opération prend environ 20 à 30 minutes.

Une fois la base de données créée, une autre fonction Lambda s'exécute, orchestrée via Step Functions. Elle vérifie que la base de données est utilisable en exécutant une simple requête de lecture, par exemple : SELECT COUNT(*) FROM email. Une fois la vérification réussie, la base de données est arrêtée, et non supprimée. Je ne paie donc que le stockage, et non la puissance de calcul.

Ensuite, la base de données restaurée la veille est supprimée. À tout moment, une réplique récemment restaurée est disponible.

J'ai mis en place ce système pour deux raisons :

Je souhaite tester en permanence la restauration des sauvegardes.

En cas d'indisponibilité de l'environnement de production, je peux rediriger le trafic vers une réplique prête à l'emploi.

Je n'utiliserai peut-être pas toujours cette solution, mais je souhaite disposer de cette option.

3. Protection contre la suppression avec Terraform et AWS

J'ai activé la protection contre la suppression à deux niveaux :

Dans la configuration Terraform

Au sein d'AWS

Ces deux protections empêchent toute suppression accidentelle.

Claude Code explique la différence entre deletion_protection et prevent_destroy, et exécute terraform plan avec demande d'autorisation.

Configuration de la protection contre la suppression. Désormais, chaque action Terraform nécessite une approbation explicite.

Techniquement, ces protections peuvent toujours être désactivées via l'interface de ligne de commande (CLI). Cependant, elles ajoutent des contraintes et empêchent les actions destructives accidentelles.

4. Protection des sauvegardes S3

Pour les sauvegardes S3, j'ai activé le versionnage. Si un élément est supprimé, les versions précédentes restent disponibles. La suppression d'un compartiment nécessite également la suppression préalable de son contenu, ce qui constitue une barrière supplémentaire.

5. Migration de l'état Terraform vers S3

Plus important encore, j'ai migré l'état Terraform vers S3.

L'état n'est plus stocké localement sur une seule machine. Terraform dispose désormais d'une vue cohérente et partagée de l'infrastructure. Cela élimine la situation initiale où je supposais que l'état était déjà distant alors qu'il était en réalité local sur mon ancienne machine, ce qui a permis la création de ressources dupliquées.

Avec l'état stocké dans S3 :

Il n'est pas lié à un seul ordinateur portable.

Il ne peut pas disparaître silencieusement lors d'un changement de machine.

Terraform dispose toujours d'une vue cohérente de l'infrastructure.

Leçons apprises :

Cet incident est de ma faute :

J'ai trop compté sur l'agent IA pour exécuter les commandes Terraform. J'ai considéré les opérations de planification, d'application et de destruction comme pouvant être déléguées. Cela a supprimé la dernière couche de sécurité.

J'ai également trop compté sur les sauvegardes, que je supposais existantes. Les sauvegardes automatiques ont été supprimées en même temps que la base de données. Je n'avais pas testé intégralement le processus de restauration.

La base de données était trop facile à supprimer. Les protections étaient insuffisantes pour ralentir les actions destructives.

En attendant le support AWS, j'ai dû envisager la possibilité d'une perte définitive des données.

Pour le cours d'ingénierie des données en cours, où les participants travaillent actuellement sur les modules finaux, j'avais déjà commencé à réfléchir à un plan de récupération. Pour les anciens cours, cela aurait été une perte définitive.

Heureusement, le support AWS a retrouvé une sauvegarde et a tout restauré.

Changements actuels

Les mesures de sécurité que j'ai mises en place sont maintenues.

Pour Terraform :

Les agents n'exécutent plus de commandes.

Chaque plan est vérifié manuellement.

Chaque action destructive est exécutée par mes soins.

Pour les AI Shipping Labs, j'envisage d'utiliser un compte AWS distinct pour le développement et la production afin d'assurer une isolation optimale avant tout lancement.

Mes projets récents

1. AI Engineering Buildcamp

J'ai terminé l'enregistrement de la section « Plateforme de surveillance DIY » pour le module de surveillance de l'AI Engineering Buildcamp.

Lors de la précédente session, le module était principalement axé sur la création de notre propre plateforme de surveillance, Pydantic LogFire étant relégué au second plan. Pour cette session, j'ai recentré l'attention sur Pydantic LogFire car son intégration est simple, la seule véritable difficulté étant l'extraction des données. J'ai veillé à expliquer comment contourner ce problème. La section « Plateforme de surveillance DIY » reste disponible en option pour une exploration approfondie.

J'ai également intégré les retours de la promotion précédente et adapté le contenu en conséquence. Les enregistrements de cette section sont maintenant terminés.

Il me reste encore quelques sections à finaliser pour le Buildcamp d'ingénierie IA d'ici la fin de la semaine.

2. Série de newsletters sur l'ingénierie IA

Cette semaine, nous avons publié un nouvel article dans le cadre de notre série de newsletters du mercredi consacrée à l'ingénierie IA. Nous y avons analysé plus de 1 000 offres d'emploi d'ingénieur IA provenant des principaux pôles technologiques du monde entier afin de comprendre comment les entreprises définissent ce rôle aujourd'hui.

Nous avons mis en lumière les points communs qui ressortent de ces offres : les différents sous-types de poste d'ingénieur IA, les responsabilités attendues des entreprises, les compétences et les outils les plus fréquemment utilisés, ainsi que les cas d'usage concrets pour lesquels les équipes recrutent.

3) Série de sessions de recherche en direct pour ingénieurs en IA

Mardi dernier, j'ai animé la troisième session en direct de ma série d'événements intitulée « Ingénierie IA : Le processus d'entretien ».

J'y ai partagé des enseignements tirés d'un vaste ensemble de données d'entretiens réels. Nous avons abordé les attentes des entreprises vis-à-vis des candidats en ingénierie IA, les types de questions techniques et conceptuelles posées en entretien, ainsi que des exemples de défis de programmation en direct.

Pour préparer cette session, j'ai analysé plus de 700 sources : rapports, discussions sur Twitter et Reddit, et interviews sur YouTube. J'en ai extrait une grande quantité de questions d'entretien, puis j'ai sélectionné les plus pertinentes. Une part importante de ce travail a consisté à filtrer, valider et catégoriser ces documents.

Ces recherches sont également publiées et mises à jour en continu dans le Guide pratique d'ingénierie de l'IA sur GitHub. N'hésitez pas à le mettre en favori et à le partager sur les réseaux sociaux si vous le trouvez utile. Vous pouvez utiliser ce modèle :

J'ai trouvé ce dépôt de guide pratique d'ingénierie de l'IA d'Alexey Grigorev, basé sur des données réelles (1 765 descriptions de poste et des retours d'expérience d'entretiens).

Idéal pour préparer les postes d'ingénieur en IA :

• Description du rôle et des compétences

• Questions d'entretien et exercices à réaliser chez soi

• Parcours d'apprentissage et idées de projets

https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main

Le dernier événement de la série, « Exercices à réaliser chez soi en ingénierie IA », aura lieu en direct sur Zoom lundi prochain. Lors de cette session, nous analyserons les projets que les entreprises demandent réellement aux candidats de réaliser à domicile et identifierons les tendances qui se dégagent de ces exercices. Inscrivez-vous à l'avance pour recevoir le lien Zoom.

4) En présentiel Atelier

[


](https://substackcdn.com/image/fetch/$s_!Z7_G!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F31785cfa-b9a5-4f35-b8c8-120d14b07599_1600x900.png)

Mardi prochain, le 10 mars, j'animerai un atelier pratique d'ingénierie des données à Exasol Xperience 2026 à Berlin.

Dans cette session, nous construirons un pipeline de données complet à partir des données de prescription du NHS britannique, soit plus d'un milliard d'enregistrements, en passant de l'ingestion brute à un système prêt pour l'analyse. Nous ingérerons l'ensemble de données, configurerons un environnement de test, construirons un entrepôt de données avec Exasol Personal sur AWS, orchestrerons le pipeline avec Kestra et explorerons les résultats via un tableau de bord Grafana.

Si vous êtes à Berlin, n'hésitez pas à participer. Les membres de la communauté DataTalks.Club peuvent assister gratuitement à la conférence avec le code EXA-VIP-RDTC. En revanche, l'atelier nécessite une inscription séparée, car la liste des participants sera vérifiée à l'entrée.

Les supports ont été préparés il y a environ un mois, et je peaufine actuellement le contenu et répète l'atelier avec l'équipe Exasol. Nous cherchons également une solution pour permettre aux participants n'ayant pas de compte AWS d'accéder à la base de données.

5) Atelier Apache Flink

Mercredi dernier, j'ai animé un atelier sur Apache Flink pour le Zoomcamp d'ingénierie des données afin de mettre à jour le module de streaming.

Le matériel original a été créé par Zach Wilson (https://open.substack.com/users/10367987-zach-wilson?utm_source=mentions), qui avait animé un stream Flink pour ce cours l'année dernière. Environ 80 à 90 % du contenu de l'atelier est basé sur son matériel, mis à jour pour fonctionner avec Flink 2.x et les versions récentes de Python (3.12, 3.9, 3.8).

Flink n'étant pas mon domaine d'expertise principal, je me suis appuyé sur le travail de Zach, qui est très pertinent. Merci encore, Zach, pour l'excellent support de cours !

Durant l'atelier, nous avons commencé par examiner l'exemple original de Zach, puis nous avons exploré un autre cas d'agrégation avec filigranes et fenêtres de verrouillage. La mise à jour du support a nécessité de nombreux tests pour garantir son bon fonctionnement. Claude Code a contribué à ces mises à jour, même si cela a demandé beaucoup d'aide.

Outils

---

[

](https://github.com/getnao/nao)

nao est un framework open source permettant de créer et de déployer des agents analytiques.

• nao : un framework open source permettant de créer et de déployer des agents analytiques qui permettent aux utilisateurs d'interroger des données en langage naturel tout en conservant un contrôle et une fiabilité de niveau ingénierie. Les équipes de données définissent un contexte structuré et versionné via l'interface de ligne de commande (CLI), s'intègrent à n'importe quelle pile de données, effectuent des tests unitaires de performance et s'hébergent elles-mêmes leurs données en toute sécurité grâce à leurs propres clés LLM. Les utilisateurs métiers bénéficient d'une interface de chat avec des visualisations natives, un raisonnement transparent et des boucles de rétroaction intégrées, comblant ainsi le fossé entre l'ingénierie analytique et la prise de décision.

• Pilot Shell : un environnement de développement professionnel pour Claude Code qui intègre les garde-fous d'ingénierie directement dans le flux de travail. Au lieu d'ajouter une structure multi-agents complexe, il impose des tests, une analyse statique du code, une mise en forme et une vérification des types à chaque modification, tout en préservant le contexte entre les sessions. Il en résulte un codage multi-agents intégrant les standards de production, permettant aux développeurs de déléguer des tâches, de s'absenter et de revenir à un code vérifié, conforme aux conventions et prêt à être déployé.

• rtk (Rust Token Killer) : un proxy CLI haute performance qui réduit la consommation de jetons LLM en filtrant et en compressant les sorties de commandes avant leur entrée dans le contexte du modèle. Dans les sessions Claude Code classiques, il réduit l'utilisation des jetons de 60 à 90 % pour les opérations courantes telles que git, les tests, la lecture de fichiers et les commandes de recherche, ce qui diminue considérablement les coûts et améliore l'efficacité du contexte. Il est spécialement conçu pour les flux de travail de développement assisté par IA où les sorties terminales volumineuses risqueraient de saturer le budget de jetons.

Ressources

[

](https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main)

Guide pratique d'ingénierie en IA : une ressource basée sur les données concernant le rôle d'ingénieur en IA – compétences, outils, questions d'entretien et parcours d'apprentissage

• Guide pratique d'ingénierie IA : une ressource basée sur les données concernant le rôle d'ingénieur en IA : compétences, outils, questions d'entretien et parcours d'apprentissage, à partir de descriptions de poste réelles et de témoignages de professionnels. Ce guide analyse les attentes réelles des entreprises vis-à-vis des ingénieurs en IA, en abordant des sujets tels que les responsabilités, les processus de recrutement, les questions d'entretien courantes et les parcours d'apprentissage adaptés à différents profils. Ce projet évolue pour devenir une référence complète pour toute personne se préparant à une carrière d'ingénieur en IA.

• Marketing pour les fondateurs : une plateforme de ressources pratiques et ciblées, conçue pour aider les fondateurs techniques à acquérir leurs 10, 100 ou 1 000 premiers utilisateurs avec un budget limité. Plutôt que de se concentrer sur des exemples de croissance, cette plateforme propose des guides pratiques couvrant les plateformes de lancement, le référencement (y compris le référencement LLM et l'AEO), la prospection, le contenu, la tarification, l'optimisation des conversions et la validation des idées. Il constitue un point de départ structuré pour l'élaboration d'une stratégie de commercialisation en phase de démarrage, axée sur la mise en œuvre plutôt que sur la théorie.

---

Édité par Valeriia Kuka