Andrej Karpathy et l'apprentissage profond : leçons pour déployer l'IA

Pourquoi l'apprentissage profond semble souvent difficile à utiliser dans des produits réels

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 :

• Répétable : il se comporte de façon prévisible sur des entrées courantes, pas seulement sur des démos triées.
• Mesurable : on peut définir « bon » par un nombre, pas une impression.
• Maintenable : on peut mettre à jour les données, les prompts ou les modèles sans tout casser.
• Opérable : on peut surveiller les défaillances, le coût, la latence et la qualité après la mise en production.

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.

Travail initial : traiter les réseaux neuronaux comme de l'ingénierie, pas de la magie

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 :

• Commencez par une baseline que vous pouvez dépasser, même si elle est simple.
• Choisissez une métrique qui décide « mieux » vs « pire ».
• Changez une seule chose à la fois pour savoir ce qui a causé le résultat.
• Inspectez les erreurs et les exemples, pas seulement le score final.

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.

Rendre les réseaux de neurones compréhensibles pour les ingénieurs qui vont les maintenir

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.

Expliquez-le comme si vous deviez le maintenir

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 :

• Quelle est l'entrée et la sortie exactes (format, limites, rédactions) ?
• Quelle baseline devez-vous battre (règles, recherche, templates, ou un modèle plus petit) ?
• À quoi ressemble le « bon » (un chiffre, une grille d'évaluation, ou les deux) ?
• Quelles défaillances sont inacceptables (sécurité, confidentialité, ton de la marque) ?
• Qui révise les résultats, et à quelle fréquence ?

La reproductibilité fait partie de l'explication

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.

Du prototype à la production : ce qui change au déploiement

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.

Les contraintes qui comptent soudainement

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 :

• Quel est le temps de réponse maximum acceptable et le coût par requête ?
• Quel est le repli quand le modèle échoue ou timeoute ?
• Quelles métriques définissent la qualité, et quels seuils déclenchent des alertes ?
• Comment prévenir les sorties non sûres ou non conformes ?
• Comment revenir en arrière rapidement si la qualité baisse ?

Il faut plus que des compétences en modèle

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.

La culture d'ingénierie : hypothèses, baselines et itération

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 :

• « Les utilisateurs accepteront une réponse suggérée si elle est correcte et correspond à leur ton. »
• « Une latence inférieure à 800 ms est requise ou les gens arrêtent de l'utiliser. »

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 :

• Adoption (qui essaye et continue d'utiliser)
• Qualité (taux d'acceptation, modifications avant envoi, pouces up/down)
• Vitesse (latence et temps jusqu'à la première sortie utile)
• Coût (tokens, compute, temps de revue humaine)
• Sécurité (violations de politique, fuites de données sensibles, tentatives de jailbreak)

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.

Étape par étape : un workflow simple pour livrer une fonctionnalité IA

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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 ».

Hypothèses claires et sorties mesurables (ce qu'il faut écrire)

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 :

• Entrées : ce que le modèle voit (champs, limites, rédactions) et ce que « assez propre » signifie
• Contrat de sortie : ce qu'il doit renvoyer (format, ton, actions autorisées)
• Éval offline : un petit jeu étiqueté avec des règles de scoring (pass/échec plus une métrique)
• Métrique online : ce que font les utilisateurs (taux d'acceptation, modifications, temps gagné, tickets rouverts)
• Garde-fous : quand refuser, poser une question, ou revenir à un flux plus simple

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.

Erreurs courantes quand les équipes ajoutent de l'IA à un produit

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 :

• Lancer sans baseline non-IA, donc l'amélioration est impossible à prouver.
• Poursuivre la qualité en ignorant latence et coût (un gain de 3 % ne vaut pas un ralentissement x5).
• Compter sur des retours vagues (« les utilisateurs aiment ») au lieu d'une instrumentation.
• Tuner sur un jeu minuscule ou trié qui ne correspond pas au trafic réel.
• Ne pas avoir de plan de rollback quand un prompt ou une mise à jour de modèle produit des sorties bizarres.

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 ».

Checklist rapide avant la mise en production

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 :

• Un énoncé du problème en un paragraphe et des utilisateurs cibles clairs.
• Une baseline mesurée (même simple).
• Une métrique online principale liée à la valeur utilisateur, plus des logs qui capturent entrées, sorties et résultats.
• Une revue sécurité : modes de défaillance probables, qui est impacté, et ce que fait l'UI (avertir, bloquer, demander confirmation).
• Un plan de rollback avec un propriétaire : ce qui déclenche le rollback et ce que vous vérifiez la première heure.

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é.

Scénario exemple : déployer une fonctionnalité de rédaction pour le support

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 :

• Temps moyen de traitement (ouvert à résolu)
• Taux d'édition (combien les agents modifient les brouillons avant envoi)
• Taux d'escalade (tickets montés vers des niveaux supérieurs)
• Taux de réouverture (tickets rouverts dans les 7 jours)
• Score de satisfaction client (si vous le suivez déjà)

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.

Étapes suivantes : appliquez ces leçons à votre prochaine release IA

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.