L'IA sans le battage médiatique : le guide de l'ingénieur qui travaille vraiment

La plupart du contenu sur l'IA en ligne se divise en deux camps : les prédictions de fin du monde avec une superintelligence, ou des affirmations enthousiates qu'un chatbot te remplacera d'ici mardi. Aucun des deux ne t'aide à livrer du code. Ce guide ignore les deux et montre comment utiliser réellement la génération actuelle d'outils IA dans de vrais projets, avec les limites clairement énoncées.

Ce qu'un LLM fait réellement

Un grand modèle de langage comme GPT-4 ou Llama 3 prédit le prochain token dans une séquence, entraîné sur des quantités énormes de texte. C'est tout. Il n'y a pas de vérificateur de faits interne, pas de mémoire persistante entre les sessions (sauf si tu en construis une), et pas de compréhension comme un humain comprend. Quand tu lui poses une question, il génère une continuation statistiquement plausible de ton prompt.

Cela a des implications pratiques : le modèle générera avec confiance une fonction Python qui appelle une méthode de bibliothèque qui n'existe pas, parce que cette méthode semble être quelque chose que la bibliothèque aurait. Exécute toujours le code. Consulte toujours la documentation de l'API. Traite la sortie du modèle comme un brouillon d'un stagiaire rapide et cultivé qui ment parfois sans le savoir.

Un vrai workflow : utiliser un LLM pour du code

Voici un pattern qui fonctionne au lieu de simplement demander à ChatGPT de « me construire une app »:

1. Écris la signature et la docstring de la fonction toi-même, en spécifiant les types et les cas limites.
2. Demande au modèle de l'implémenter selon ce spec exact.
3. Écris tes propres tests séparé — ne demande pas au modèle d'écrire les tests pour le code qu'il vient d'écrire, il aura tendance à écrire des tests qui passent trivalement.
4. Exécute les tests. Renvoie les échecs comme de nouveaux prompts, pas des affirmations vagues du type « ça ne marche pas ».

def parse_duration(text: str) -> int:
    """
    Parse strings like '1h30m', '45s', '2d' into total seconds.
    Raise ValueError on invalid input.
    """

Donner au modèle ce contrat exact produit une meilleure sortie qu'une description vague, et ça te donne quelque chose de concret pour tester.

La génération augmentée par récupération, en termes simples

RAG est lancé comme un buzzword mais le mécanisme est simple : au lieu de t'appuyer sur ce que le modèle a mémorisé pendant l'entraînement, tu récupères les documents pertinents au moment de la requête et tu les glisses dans le prompt.

Une configuration basique :

1. Divise tes documents (500-1000 tokens chacun est un bon point de départ).
2. Encode chaque chunk avec un modèle comme text-embedding-3-small ou un modèle open comme bge-small-en.
3. Stocke les vecteurs dans quelque chose comme Postgres avec pgvector, ou un store dédié comme Qdrant.
4. Au moment de la requête, encode la question de l'utilisateur, exécute une recherche de similarité (la distance cosinus est standard), et récupère les top-k chunks dans le prompt à côté de la question.

SELECT content FROM docs
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

C'est pourquoi un chatbot entraîné sur des données jusqu'à une certaine date peut toujours répondre aux questions sur ton wiki interne d'il y a une semaine. Il n'est pas en train de raisonner sur ton entreprise — il lit tes documents et les résume.

Où le ML classique gagne toujours

Tout problème n'a pas besoin d'un transformer. Si tu prédis la résiliation à partir de données tabulaires structurées — l'âge du compte, la fréquence d'utilisation, les tickets de support — un modèle d'arbre boosté par gradient comme XGBoost ou LightGBM surpassera généralement une approche basée sur LLM, s'entraînera en minutes au lieu d'heures, et coûtera une fraction du prix à exécuter. Préfère RandomForestClassifier de scikit-learn ou XGBoost à un appel d'API, surtout quand tes données tiennent dans un tableur et ta variable cible est un nombre ou une catégorie clean.

Le coût et la latence sont des contraintes de conception, pas des détails mineurs

Un appel de classe GPT-4 coûte de l'argent réel par token et prend des secondes réelles pour revenir. Si tu construis une fonctionnalité qui s'exécute à chaque chargement de page pour chaque utilisateur, ça additionne vite et la latence sera visible. Cache agressivement, utilise un modèle plus petit comme GPT-4o-mini ou un Llama 3 8B local pour tout ce qui n'a pas besoin du raisonnement de haut niveau, et réserve les appels du modèle coûteux pour les parties de ton pipeline où la qualité compte vraiment.

Le mode d'échec que personne ne t'avertit

Les modèles hallucinent plus, pas moins, quand tu leur demandes des choses légèrement en dehors de leur distribution d'entraînement — des versions obscures de bibliothèques, du jargon interne de l'entreprise, les numéros CVE récents. Si la réponse doit être exactement juste (un avis de sécurité, une citation légale, une dose médicale), ne fais pas confiance à la génération seule. Vérifie contre une source primaire à chaque fois, et construis cette étape de vérification dans ton pipeline plutôt que de la confier à une revue humaine après coup.

Les outils IA sont genuinely utiles une fois que tu arrêtes de t'attendre à ce qu'ils pensent et que tu commences à les traiter comme un pattern-matcher rapide que tu dois vérifier. Construis l'étape de vérification dès le premier jour et tu obtiendras une vraie valeur au lieu d'un flux de bêtises confiantes.

Si tu veux aller plus loin, jette un œil aux Python et Data Science tracks de Korra Studio pour les fondamentaux qui rendent le travail avec ces outils vraiment productif.