L'AI engineering, expliqué à ceux qui découvrent le métier

Non. Le protocole GSD encadre chaque étape : contexte écrit, plan relu, exécution, vérification humaine. L'agent accélère l'exécution ; il n'a jamais le dernier mot. Les schémas plus haut montrent qui tient quelle étape.

Sans ce cadre, un agent dérive : il invente une règle, saute une contrainte, livre quelque chose qui fonctionne techniquement mais rate l'objectif. La relecture n'est pas un luxe — c'est ce qui sépare un studio d'une machine à produire du texte.

En pratique : l'humain écrit le brief et accepte le plan ; l'agent produit ; l'humain relit le livrable avant toute mise en ligne. Si une étape n'a pas de responsable nommé, on ne la lance pas.

En partie. C'est un profil à mi-chemin entre développeur et analyste : il code, il met en place la mesure, il sait lire un tunnel de conversion et un test statistique — et il pilote des agents plutôt que de tout écrire à la main du début à la fin.

Ce n'est pas quelqu'un qui se contente de bien formuler ses demandes à ChatGPT, ni un chercheur qui entraîne des modèles. Le métier, ici, c'est de mener un projet jusqu'à un résultat mesurable : une nouvelle version de page en ligne, un prototype cliquable, un tableau de bord qui répond à une question.

Si vous cherchez uniquement un développeur pour dérouler une liste de tickets, une équipe interne ou une société de services fera mieux. Si vous cherchez quelqu'un qui relie mesure, produit et agents, c'est ce studio.

Non. Ce n'est ni de la recherche, ni de la science des données au sens académique : on ne fabrique pas de modèle d'IA maison. On assemble des modèles existants — ceux de Google, d'OpenAI, d'Anthropic — et des outils d'analyse dans un processus qui produit un livrable.

La valeur n'est pas « l'IA ». C'est le protocole : une mémoire neuve à chaque étape, plusieurs recherches en parallèle, un plan relu, une exécution par vagues, une vérification. Un modèle sans cadre produit du texte ; un protocole produit un site, un test, un écran.

Si votre besoin est un modèle entraîné sur vos propres données — ce qu'on appelle le fine-tuning — ce n'est pas l'offre. On peut en revanche cadrer la façon dont des agents s'appuient sur vos données, en local, sans les envoyer n'importe où.

Vos exports de données sont analysés en local, sur une machine du studio, avec des outils d'analyse classiques. Aucune donnée client n'est envoyée à un modèle d'IA sans accord écrit préalable. Le périmètre — quels fichiers, quelles colonnes, quel outil — est fixé au démarrage.

C'est volontairement plus strict qu'un « on collera ça dans ChatGPT ». Un export CRM, un fichier de conversions ou un journal de navigation n'a rien à faire dans un outil grand public par défaut. Si un agent cloud est utile, on le dit, on limite les colonnes, on anonymise ce qu'il faut.

Vous restez propriétaire des données et des livrables. Le studio n'entraîne rien avec vos fichiers et ne les réutilise pas sur un autre client.

Parce que l'instrumentation remplace la coordination. Un interlocuteur, des agents outillés et un protocole GSD tiennent le rythme d'une petite équipe, sans les frais ni les délais d'une structure à plusieurs étages.

La difficulté n'est plus d'écrire le cahier des charges : c'est d'exécuter en parallèle et de vérifier. C'est pour ça que GSD lance plusieurs agents de recherche en même temps, enchaîne des vagues d'exécution et impose une vérification — plutôt que d'ajouter des personnes et des réunions.

Ça a un plafond : un programme international à vingt contributeurs n'est pas le bon cas. Un tunnel de conversion, un produit, un outil interne, oui. L'appel sert à voir de quel côté vous êtes.

GSD est un chef d'orchestre léger : une mémoire neuve à chaque étape (pour éviter que le fil de conversation se dégrade), plusieurs recherches en parallèle, un plan relu, une exécution par vagues, une vérification. Ce n'est pas un outil de plus à apprendre de votre côté — c'est la cuisine interne du studio.

GitHub Spec Kit, OpenSpec, Taskmaster ou BMAD font autre chose, et le font bien : cahier des charges d'abord, description des écarts sur un produit existant, arbre de tâches, un agent par rôle. Ils aident à écrire le plan. Après deux ans d'usage réel, la vraie difficulté est ailleurs : exécuter en parallèle et relire — d'où GSD.

Vous n'avez pas à choisir l'outil. Vous voyez des livrables et un rythme. Le détail des alternatives est dans l'onglet « Alternatives » plus haut sur cette page.

C'est un simple fichier de règles que l'agent doit suivre pour un type de livrable donné : un audit de conversion, un plan de marquage, un écran de prototype. Le studio appelle ça un « skill ». Sans lui, l'agent improvise ; avec lui, il répète un geste déjà éprouvé.

Les projets du studio partagent une bibliothèque de ces fichiers. C'est ce qui évite de réinventer « comment on écrit un test » à chaque mission. Ça ne remplace pas la relecture : ça rend l'exécution régulière.

Vous n'avez rien à maintenir. Vous profitez du fait qu'ils existent — et chaque mission qui se passe bien en enrichit un, au lieu de rester dans la tête d'une seule personne.

Pour les agents : Cursor, Claude Code, Kilo Code, Copilot, Cline, le protocole GSD et les règles projet. Pour l'analyse : Python et SQL. Pour la mesure : GA4, GTM et Looker Studio. Pour les pages : HTML, Tailwind, parfois Webflow.

La liste évolue ; le protocole reste. On n'impose pas ses outils : on s'adapte à ce que vous avez déjà — votre outil de gestion de contenu, votre base de données, votre compte publicitaire. L'outil sert l'objectif, pas l'inverse.

Si un outil est un verrou (licence, donnée qui ne peut pas sortir), on le traite dans le cadrage. Pas de surprise le jour 3.

Ça dépend du livrable, pas de « l'IA ». Un prototype cliquable : quelques jours à quelques semaines. Un premier test de conversion lisible : souvent quelques semaines, le temps d'accumuler assez de visiteurs. Un ensemble de pages bien référencées : des mois. Un logiciel en ligne utilisable : quelques semaines de développement après un prototype cadré.

Les agents accélèrent la production, pas le rythme auquel votre trafic arrive ni le temps qu'un test met à devenir fiable. Promettre une première place Google en quinze jours parce qu'on écrit plus vite serait mensonger.

Le premier effet visible, lui, est rapide : un cadrage écrit sous 48 h après l'appel, avec le problème, le KPI et la première étape.

Oui — c'est même le cas le plus fréquent. Un tunnel de conversion qui perd des visiteurs, une mesure GA4 en laquelle personne n'a confiance, une maquette jamais testée auprès d'utilisateurs, une feuille de route produit à l'arrêt. On part de l'existant, on ne demande pas de tout recommencer.

L'AI engineering sert alors à accélérer un morceau du chantier — analyse de données, variantes de pages, écrans, contenus — pendant que votre équipe continue le reste. Le studio n'a pas besoin de « prendre le compte » pour être utile.

Si le chantier est déjà bien cadré par une agence ou une équipe interne, on se cale sur leurs rituels. L'appel sert à voir où on s'insère, pas à tout reconstruire.