Andrej Karpathy montre comment transformer les réseaux neuronaux en produits avec des hypothèses claires, des métriques et un flux de travail orienté ingénierie.
Une démo d'apprentissage profond peut sembler magique. Un modèle écrit un paragraphe propre, reconnaît un objet ou répond à une question difficile. Puis on essaie de transformer cette démo en un bouton que les gens appuient tous les jours, et les choses se compliquent. Le même prompt se comporte différemment, les cas limites s'accumulent, et l'effet « wow » devient un ticket support.
Cet écart explique pourquoi le travail d'Andrej Karpathy a trouvé un écho chez les équipes. Il a promu un état d'esprit où les réseaux neuronaux ne sont pas des artefacts mystérieux. Ce sont des systèmes que l'on conçoit, teste et maintient. Les modèles ne sont pas inutiles. Les produits exigent simplement de la cohérence.
Quand les équipes disent qu'elles veulent une IA « pratique », elles veulent généralement quatre choses :
Les équipes ont du mal parce que l'apprentissage profond est probabiliste et sensible au contexte, alors que les produits sont jugés sur la fiabilité. Un chatbot qui répond correctement à 80 % des questions peut toujours sembler cassé si les 20 % restants sont confiants, faux et difficiles à détecter.
Prenez un assistant « réponse automatique » pour le support client. Ça marche bien sur quelques tickets choisis à la main. En production, les clients écrivent en argot, joignent des captures d'écran, mélangent les langues ou posent des questions sur des cas limites de politique. Il faut alors des garde-fous, un comportement clair de refus, et une façon de mesurer si l'ébauche a réellement aidé un agent.
Beaucoup ont découvert le travail de Karpathy via des exemples pratiques, pas des mathématiques abstraites. Même les premiers projets faisaient un point simple : les réseaux neuronaux deviennent utiles quand on les traite comme un logiciel qu'on peut tester, casser et réparer.
Au lieu de s'arrêter à « le modèle fonctionne », l'accent se déplace vers le fait de le faire fonctionner sur des données réelles et désordonnées. Cela inclut les pipelines de données, les runs d'entraînement qui échouent pour des raisons banales, et les résultats qui changent quand on touche une petite chose. Dans ce monde, l'apprentissage profond cesse d'être mystique et devient de l'ingénierie.
Une approche à la Karpathy, c'est moins des astuces secrètes et plus des habitudes :
Cette fondation compte ensuite parce que l'IA produit est surtout le même jeu, avec des enjeux plus élevés. Si vous ne construisez pas le métier tôt (entrées claires, sorties claires, runs répétables), livrer une fonctionnalité IA devient de la devinette.
Une grande partie de l'impact de Karpathy est d'avoir traité les réseaux neuronaux comme quelque chose sur lequel on peut raisonner. Des explications claires transforment le travail d'un « système de croyance » en ingénierie.
C'est important pour les équipes, car la personne qui livre le premier prototype n'est souvent pas celle qui le maintiendra. Si vous ne pouvez pas expliquer ce que fait un modèle, vous ne pourrez probablement pas le déboguer, et vous ne pourrez certainement pas le supporter en production.
Forcez la clarté tôt. Avant de construire la fonctionnalité, écrivez ce que le modèle voit, ce qu'il renvoie, et comment vous saurez s'il s'améliore. La plupart des projets IA échouent sur les bases, pas sur les maths.
Une courte checklist qui rapporte plus tard :
Une pensée claire se manifeste par des expériences disciplinées : un script unique que vous pouvez relancer, des jeux d'évaluation fixes, des prompts versionnés et des métriques enregistrées. Les baselines vous gardent honnêtes et rendent les progrès visibles.
Un prototype prouve qu'une idée peut marcher. Une fonctionnalité déployée prouve qu'elle marche pour de vraies personnes, dans des conditions désordonnées, tous les jours. C'est dans cet écart que beaucoup de projets IA butent.
Une démo de recherche peut être lente, coûteuse et fragile, tant qu'elle montre la capacité. La production inverse les priorités. Le système doit être prévisible, observable et sûr même quand les entrées sont étranges, les utilisateurs impatients et le trafic en pic.
En production, la latence est une fonctionnalité. Si le modèle met 8 secondes, l'utilisateur abandonne ou spamme le bouton, et vous payez pour chaque nouvelle tentative. Le coût devient aussi une décision produit, car un petit changement de prompt peut doubler votre facture.
La surveillance est indispensable. Il faut savoir non seulement que le service est en ligne, mais que les sorties restent dans une qualité acceptable dans le temps. Les dérives de données, les nouveaux comportements utilisateurs et les changements en amont peuvent dégrader silencieusement la performance sans déclencher d'erreur.
Les contrôles de sécurité et de conformité passent de « agréable à avoir » à requis. Il faut gérer les requêtes nuisibles, les données privées et les cas limites de façon cohérente et testable.
Les équipes finissent généralement par répondre aux mêmes questions :
Un prototype peut être construit par une seule personne. Le déploiement demande en général que le produit définisse le succès, que les données valident les entrées et les jeux d'éval, que l'infra le fasse tourner fiablement, et que la QA teste les modes de défaillance.
« Ça marche sur ma machine » n'est pas un critère de release. Une mise en production signifie que ça marche pour les utilisateurs sous charge, avec du logging, des garde-fous et un moyen de mesurer si ça aide ou nuit.
L'influence de Karpathy est culturelle, pas seulement technique. Il a traité les réseaux neuronaux comme quelque chose que l'on peut construire, tester et améliorer avec la même discipline que n'importe quel système d'ingénierie.
Tout commence par écrire les hypothèses avant d'écrire du code. Si vous ne pouvez pas énoncer ce qui doit être vrai pour que la fonctionnalité fonctionne, vous ne pourrez pas la déboguer plus tard. Exemples :
Ce sont des déclarations testables.
Les baselines viennent ensuite. Une baseline est la chose la plus simple qui puisse marcher, et c'est votre vérification de réalité. Ça peut être des règles, un template de recherche ou même « ne rien faire » avec une bonne interface. Des baselines solides vous protègent de passer des semaines sur un modèle sophistiqué qui ne dépasse pas quelque chose de simple.
L'instrumentation rend l'itération possible. Si vous ne regardez que des démos, vous naviguez à l'impression. Pour beaucoup de fonctionnalités IA, un petit ensemble de chiffres suffit déjà pour savoir si vous progressez :
Puis itérez en boucles courtes. Changez une chose, comparez à la baseline, et gardez un journal simple de ce que vous avez essayé et de ce qui a bougé. Si le progrès est réel, il apparaît sur un graphe.
Livrer de l'IA marche mieux quand on la traite comme de l'ingénierie : objectifs clairs, une baseline, et des boucles de feedback rapides.
Formulez le problème utilisateur en une phrase. Écrivez-le comme une plainte que vous pourriez entendre : « Les agents support passent trop de temps à rédiger des réponses aux questions courantes. » Si vous ne pouvez pas le dire en une phrase, la fonctionnalité est probablement trop vaste.
Choisissez un résultat mesurable. Prenez un seul chiffre que vous pouvez suivre chaque semaine. Bons choix : temps gagné par tâche, taux d'acceptation du premier brouillon, réduction des modifications, ou taux de déviation de tickets. Décidez de ce qui est « assez bon » avant de construire.
Définissez la baseline à battre. Comparez à un template simple, une approche basée sur des règles ou « humain seulement ». Si l'IA ne bat pas la baseline sur votre métrique choisie, ne la déployez pas.
Concevez un petit test avec des données représentatives. Rassemblez des exemples qui reflètent la réalité, y compris les cas brouillons. Gardez un petit jeu d'éval sur lequel vous ne « vous entraînez pas mentalement » en le relisant chaque jour. Écrivez ce qui compte comme réussite et ce qui compte comme échec.
Déployez derrière un flag, recueillez des retours et itérez. Commencez avec un petit groupe interne ou un faible pourcentage d'utilisateurs. Enregistrez l'entrée, la sortie et si cela a aidé. Corrigez d'abord le principal mode de défaillance, puis relancez le même test pour voir un vrai progrès.
Un pattern pratique pour les outils de rédaction : mesurez « secondes jusqu'à l'envoi » et « pourcentage de brouillons utilisés avec peu de modifications ».
Beaucoup d'échecs de fonctionnalités IA ne sont pas des échecs de modèle. Ce sont des échecs « on n'a jamais convenu de ce à quoi ressemble le succès ». Si vous voulez que l'apprentissage profond paraisse pratique, écrivez les hypothèses et les mesures avant d'écrire plus de prompts ou d'entraîner d'autres modèles.
Commencez par des hypothèses qui peuvent casser votre fonctionnalité en usage réel. Les plus courantes concernent les données et les personnes : le texte d'entrée est dans une langue, les utilisateurs demandent une intention à la fois, l'UI fournit assez de contexte, les cas limites sont rares, et les patterns d'hier seront encore vrais le mois prochain (dérive). Indiquez aussi ce que vous n'allez pas gérer pour l'instant, comme le sarcasme, les conseils juridiques ou les longs documents.
Transformez chaque hypothèse en quelque chose que vous pouvez tester. Un format utile : « Étant donné X, le système doit faire Y, et on peut le vérifier par Z. » Restez concret.
Cinq choses à écrire sur une page :
Séparez volontairement offline et online. Les métriques offline vous disent si le système a appris la tâche. Les métriques online disent si la fonctionnalité aide les humains. Un modèle peut bien scorer offline et encore irriter les utilisateurs parce qu'il est lent, trop confiant, ou faux sur les cas qui comptent.
Définissez « assez bon » avec des seuils et des conséquences. Exemple : « Offline : au moins 85 % correct sur l'ensemble d'éval ; Online : 30 % des brouillons acceptés avec peu de modifications. » Si vous manquez un seuil, décidez à l'avance ce que vous faites : garder derrière un toggle, réduire le rollout, router les cas à faible confiance vers un template, ou mettre en pause et collecter plus de données.
Les équipes traitent souvent une fonctionnalité IA comme une simple retouche d'UI : la déployer, voir ce qui se passe, ajuster plus tard. Cela casse vite car le comportement d'un modèle peut changer avec des prompts, la dérive et de petits ajustements. Le résultat est beaucoup d'effort sans preuve claire que ça aide.
Une règle pratique : si vous ne pouvez pas nommer la baseline et la mesure, vous n'êtes pas encore prêt à déployer.
Les modes de défaillance les plus courants :
Exemple concret : vous ajoutez de l'IA pour rédiger des réponses support. Si vous ne suivez que les pouces up, vous pouvez rater que les agents mettent plus de temps à relire les brouillons, ou que les réponses sont exactes mais trop longues. De meilleures mesures sont « % envoyés avec peu de modifications » et « médiane du temps jusqu'à l'envoi ».
Traitez le jour du release comme un passage de témoin d'ingénierie, pas une démo. Vous devez pouvoir expliquer, en termes simples, ce que fait la fonctionnalité, comment vous savez qu'elle marche, et ce que vous ferez quand elle cassera.
Avant de déployer, assurez-vous d'avoir :
Gardez aussi un ensemble d'éval offline qui ressemble au trafic réel, inclut des cas limites, et reste assez stable pour comparer sur plusieurs semaines. Quand vous changez prompts, modèles ou nettoyage de données, relancez le même set et voyez ce qui a bougé.
Une équipe support veut un assistant qui rédige des réponses dans la vue ticket. L'agent n'envoie pas les messages automatiquement. Il propose un brouillon, met en évidence les faits clés utilisés, et demande à l'agent de relire et modifier avant l'envoi. Ce choix garde le risque bas pendant la phase d'apprentissage.
Commencez par décider ce que « mieux » signifie en chiffres. Choisissez des résultats mesurables dès le premier jour en utilisant les logs existants :
Avant d'utiliser un modèle, fixez une baseline ennuyeuse mais réelle : des templates sauvegardés plus une couche de règles simple (détecter remboursement vs expédition vs réinitialisation de mot de passe, puis pré-remplir le meilleur template). Si l'IA ne bat pas cette baseline, elle n'est pas prête.
Faites un petit pilote. Rendez-le opt-in pour quelques agents, limité à une catégorie de ticket (par exemple, statut de commande). Ajoutez un retour rapide sur chaque brouillon : « utile » ou « pas utile », plus une courte raison. Capturez ce que l'agent a changé, pas seulement s'il a cliqué sur un bouton.
Définissez des critères de mise en production à l'avance pour ne pas deviner ensuite. Par exemple : le temps de traitement s'améliore de 10 % sans augmenter l'escalade ni le taux de réouverture, et les agents acceptent les brouillons avec peu de modifications au moins 30 % du temps.
Décidez aussi ce qui déclenche un rollback : une hausse des escalades, une baisse de la satisfaction ou des erreurs politiques répétées.
Choisissez une idée IA que vous pouvez livrer en 2 à 4 semaines. Gardez-la assez petite pour pouvoir la mesurer, la déboguer et la retirer sans drame. L'objectif n'est pas de prouver que le modèle est intelligent. L'objectif est d'améliorer de façon fiable un résultat utilisateur par rapport à ce que vous avez déjà.
Transformez l'idée en un plan d'une page : ce que fait la fonctionnalité, ce qu'elle ne fait pas, et comment vous saurez qu'elle fonctionne. Incluez une baseline et la métrique exacte que vous suivrez.
Si vous voulez accélérer l'implémentation, Koder.ai (koder.ai) est construit pour créer des apps web, serveurs et mobiles via une interface de chat, avec des fonctionnalités comme snapshots/rollback et export du code source quand vous avez besoin d'un contrôle plus profond.
L'habitude à conserver est simple : chaque changement IA doit être accompagné d'une hypothèse écrite et d'une sortie mesurable. C'est ainsi que l'apprentissage profond cesse d'être magique et devient un travail que l'on peut livrer.
Parce que les démos sont généralement construites sur des entrées propres et triées sur le volet et jugées à l'impression, alors que les produits affrontent des entrées désordonnées, la pression des utilisateurs et une utilisation répétée.
Pour réduire l'écart, définissez un contrat d'entrée/sortie, mesurez la qualité sur des données représentatives et concevez des solutions de repli pour les timeouts et les cas de faible confiance.
Choisissez une seule métrique liée à la valeur utilisateur que vous puissiez suivre chaque semaine. Bons choix par défaut :
Décidez de la cible “suffisamment bonne” avant d'ajuster les prompts ou les modèles.
Utilisez l'alternative la plus simple qui pourrait raisonnablement être déployée :
Si l'IA ne bat pas la baseline sur la métrique principale (sans casser la latence/le coût), ne la déployez pas.
Gardez un petit ensemble qui ressemble au trafic réel, pas seulement des exemples optimaux.
Règles pratiques :
Cela rend les progrès visibles et réduit les régressions accidentelles.
Commencez par des garde-fous prévisibles et testables :
Considérez les garde-fous comme des exigences produit, pas une finition optionnelle.
Surveillez à la fois la santé du système et la qualité des sorties :
Enregistrez aussi entrées/sorties (avec contrôles de confidentialité) pour reproduire les erreurs et corriger les motifs les plus fréquents.
Fixez un budget max dès le départ : latence cible et coût max par requête.
Puis réduisez les dépenses sans deviner :
Un petit gain de qualité vaut rarement un coût ou un ralentissement important en production.
Déployez derrière un flag et étalez le déploiement.
Plan de déploiement pratique :
Le rollback n'est pas un échec ; c'est une partie de la maintenabilité de l'IA.
Rôles minimums à couvrir (même si une personne porte plusieurs casquettes) :
Le succès vient quand tout le monde s'accorde sur la métrique, la baseline et le plan de rollback.
Utilisez-le quand vous voulez passer de l'idée à une application fonctionnelle rapidement, tout en gardant la discipline d'ingénierie.
Flux de travail pratique :
L'outil aide à accélérer l'itération ; il faut toujours des hypothèses claires et des sorties mesurables.
