IA Locale et Journalisme : Une Exploration

Le chant des sirènes de l’intelligence artificielle se fait plus fort, promettant efficacité et transformation dans tous les secteurs. Une perspective particulièrement séduisante est d’exécuter de puissants modèles d’IA directement sur des ordinateurs personnels, contournant la dépendance au cloud, les frais d’abonnement et les préoccupations relatives à la confidentialité des données. Des géants comme Google, Meta et Mistral AI ont rendu des Large Language Models (LLMs) sophistiqués librement disponibles au téléchargement. Mais cette accessibilité se traduit-elle par une utilité pratique ? Ces esprits numériques, confinés au silicium d’un ordinateur de bureau ou portable, peuvent-ils réellement augmenter des flux de travail complexes comme l’écriture journalistique ? Ce compte rendu détaille une expérience approfondie conçue pour répondre précisément à cette question.

Préparer le Terrain : L’Expérience d’IA Locale

Pendant plusieurs mois, un effort dédié a été entrepris pour évaluer les performances réelles de divers LLMs librement téléchargeables fonctionnant entièrement sur du matériel local. La liste des modèles examinés était diversifiée, reflétant le paysage en évolution rapide de l’IA open-source :

• Google Gemma (spécifiquement la version 3)
• Meta Llama (version 3.3)
• Anthropic Claude (version 3.7 Sonnet – bien que typiquement basé sur le cloud, son inclusion suggère des tests larges)
• Plusieurs itérations de Mistral AI (incluant Mistral, Mistral Small 3.1, Mistral Nemo et Mixtral)
• IBM Granite (version 3.2)
• Alibaba Qwen (version 2.5)
• DeepSeek R1 (une couche de raisonnement souvent appliquée sur des versions distillées de Qwen ou Llama)

L’objectif principal était ambitieux mais pratique : déterminer si ces IA exécutées localement pouvaient transformer des transcriptions brutes d’interviews en articles peaufinés et publiables. Cela impliquait d’évaluer non seulement la faisabilité technique – le matériel pouvait-il supporter la charge ? – mais aussi la qualité de la sortie – le texte résultant était-il utilisable ? Il est crucial de déclarer d’emblée que l’obtention d’un article entièrement automatisé et prêt à publier s’est avérée illusoire. L’objectif principal s’est déplacé vers la compréhension des capacités et limitations réelles de l’IA embarquée actuelle à travers ce cas d’usage spécifique et exigeant.

La méthodologie choisie s’articulait autour d’un prompt substantiel. Celui-ci comprenait environ 1 500 tokens (environ 6 000 caractères ou deux pages de texte complètes) décrivant méticuleusement la structure, le style et le ton souhaités del’article. À cet ensemble d’instructions s’ajoutait la transcription de l’interview elle-même, représentant en moyenne environ 11 000 tokens pour une conversation typique de 45 minutes. La taille considérable de cette entrée combinée (dépassant souvent 12 500 tokens) surpasse généralement les limites d’utilisation gratuite de nombreuses plateformes d’IA en ligne. Cette contrainte soulignait la justification de l’exploration du déploiement local, où le traitement reste gratuit quelle que soit la taille de l’entrée, limité uniquement par les capacités de la machine.

L’exécution de ces tests impliquait l’utilisation de LM Studio, un logiciel communautaire populaire qui fournit une interface conviviale de type chatbot pour interagir avec les LLMs fonctionnant localement. LM Studio intègre commodément des fonctions pour télécharger diverses versions de modèles, bien que la source principale de ces modèles librement disponibles reste le dépôt Hugging Face, une plaque tournante centrale pour la communauté de l’IA.

Naviguer dans le Labyrinthe Technique : Matériel, Mémoire et Taille du Modèle

Le voyage dans le traitement local de l’IA a rapidement révélé une interaction complexe entre le logiciel et le matériel. La qualité et la vitesse de la sortie de l’IA étaient intimement liées aux ressources disponibles sur la machine de test – un Mac équipé d’un système sur puce (SoC) Apple Silicon M1 Max et d’une généreuse quantité de 64 Go de RAM. De manière critique, cette architecture dispose de l’Architecture Mémoire Unifiée (UMA), permettant à 48 Go de RAM d’être partagés dynamiquement entre les cœurs de processeur (CPU), les cœurs graphiques (GPU – utilisés pour l’accélération vectorielle) et les cœurs de traitement neuronal (NPU – utilisés pour l’accélération matricielle).

Plusieurs facteurs techniques clés se sont révélés décisifs :

1. Paramètres du Modèle : Les LLMs sont souvent mesurés par leur nombre de paramètres (des milliards, typiquement). Les modèles plus grands possèdent généralement une connaissance et une nuance accrues. Cependant, ils exigent beaucoup plus de mémoire.
2. Quantification : Cela fait référence à la précision utilisée pour stocker les paramètres du modèle (par exemple, 8 bits, 4 bits, 3 bits). Une précision en bits inférieure réduit considérablement l’empreinte mémoire et augmente la vitesse de traitement, mais souvent au détriment de la précision et de la qualité de sortie (introduisant des erreurs, des répétitions ou un langage absurde).
3. Fenêtre de Contexte : Cela définit la quantité maximale d’informations (prompt + données d’entrée) que l’IA peut considérer en même temps, mesurée en tokens. La taille de fenêtre requise est dictée par la tâche ; dans ce cas, le grand prompt et la transcription nécessitaient une fenêtre substantielle.
4. RAM Disponible : La quantité de mémoire limite directement quels modèles (et à quel niveau de quantification) peuvent être chargés et exécutés efficacement.

Le point idéal, offrant le meilleur équilibre entre qualité et faisabilité sur la machine de test au moment de l’évaluation, a été atteint en utilisant le modèle Gemma de Google avec 27 milliards de paramètres, quantifié à 8 bits (version ‘27B Q8_0’). Cette configuration fonctionnait dans une fenêtre de contexte de 32 000 tokens, gérant confortablement l’entrée d’environ 15 000 tokens (instructions + transcription). Elle tournait sur le matériel Mac spécifié, utilisant les 48 Go de mémoire partagée.

Dans ces conditions optimales, la vitesse de traitement a été mesurée à 6,82 tokens par seconde. Bien que fonctionnel, c’est loin d’être instantané. Les améliorations de vitesse sans sacrifier la qualité de sortie dépendent principalement d’un matériel plus rapide – spécifiquement, des SoCs avec des fréquences d’horloge plus élevées (GHz) ou un plus grand nombre de cœurs de traitement (CPU, GPU, NPU).

Tenter de charger des modèles avec beaucoup plus de paramètres (par exemple, 32 milliards, 70 milliards) a rapidement atteint le plafond de mémoire. Ces modèles plus grands soit ne parvenaient pas à se charger entièrement, soit produisaient une sortie sévèrement tronquée et inutilisable (comme un seul paragraphe au lieu d’un article complet). Inversement, l’utilisation de modèles avec moins de paramètres, tout en libérant de la mémoire, entraînait une baisse notable de la qualité d’écriture, caractérisée par des répétitions et des idées mal articulées. De même, l’emploi d’une quantification plus agressive (réduisant les paramètres à 3, 4, 5 ou 6 bits) augmentait la vitesse mais dégradait sévèrement la sortie, introduisant des erreurs grammaticales et même des mots inventés.

La taille de la fenêtre de contexte requise, déterminée par les données d’entrée, est essentiellement non négociable pour la tâche. Si les données d’entrée exigent une fenêtre qui, combinée à la taille du modèle choisi et à la quantification, dépasse la RAM disponible, le seul recours est de sélectionner un modèle plus petit, compromettant inévitablement la qualité potentielle du résultat final pour rester dans les limites de la mémoire.

La Quête de la Qualité : Quand la Structure Rencontre la Substance (ou son Absence)

L’IA exécutée localement a-t-elle réussi à générer des articles utilisables ? Oui et non. Les textes générés présentaient souvent une structure étonnamment bonne. Ils adhéraient généralement au format demandé, comportant :

• Un angle ou un focus discernable.
• Un flux cohérent à travers des sections thématiques.
• Des citations de la transcription placées de manière appropriée.
• Des titres accrocheurs et des phrases de conclusion.

Cependant, une faille critique est apparue de manière constante sur tous les LLMs testés, y compris ceux comme DeepSeek R1, spécifiquement conçus pour un raisonnement amélioré : une incapacité fondamentale à discerner et prioriser correctement la pertinence de l’information au sein de l’interview. Les modèles d’IA manquaient systématiquement le cœur de la conversation, se concentrant sur des points secondaires ou des détails tangentiels.

Le résultat était souvent des articles grammaticalement corrects et bien organisés, mais finalement superficiels et inintéressants. Dans certains cas, l’IA consacrait des passages significatifs et bien argumentés à énoncer l’évidence – par exemple, en développant longuement que l’entreprise interviewée opère sur un marché avec des concurrents. Cela mettait en évidence un fossé entre la compétence linguistique (former des phrases cohérentes) et la compréhension véritable (saisir l’importance et le contexte).

De plus, le style de sortie variait considérablement entre les modèles :

• Llama 3.x de Meta : Au moment des tests, produisait des phrases souvent alambiquées et difficiles à analyser.
• Modèles Mistral & Gemma : Montraient une tendance vers un style ‘marketing speak’, employant des adjectifs effusifs et un cadrage positif mais manquant de substance concrète et de détails spécifiques.
• Qwen d’Alibaba : Étonnamment, dans les contraintes de la configuration de test, ce modèle chinois a produit une des proses les plus esthétiquement agréables en français (la langue de l’équipe d’évaluation originale).
• Mixtral 8x7B : Initialement, ce modèle ‘mixture of experts’ (combinant huit modèles plus petits et spécialisés de 7 milliards de paramètres) était prometteur. Cependant, le faire tenir dans la contrainte de mémoire de 48 Go nécessitait une quantification agressive à 3 bits, ce qui entraînait des erreurs de syntaxe importantes. Une version quantifiée à 4 bits (‘Q4_K_M’) offrait initialement un meilleur compromis, mais des mises à jour ultérieures du logiciel LM Studio ont augmenté son empreinte mémoire, faisant que cette configuration produisait également des résultats tronqués.
• Mistral Small 3.1 : Un modèle plus récent avec 24 milliards de paramètres en quantification 8 bits s’est révélé être un concurrent sérieux. Sa qualité de sortie approchait celle du modèle Gemma 27B, et il offrait un léger avantage de vitesse, traitant à 8,65 tokens par seconde.

Cette variation souligne que le choix d’un LLM ne concerne pas seulement la taille ou la vitesse ; les données d’entraînement sous-jacentes et l’architecture influencent considérablement son style d’écriture et ses biais potentiels.

Architecture Matérielle : Le Héros Méconnu de l’IA Locale

Les expériences ont mis en lumière un facteur crucial, souvent négligé : l’architecture matérielle sous-jacente, spécifiquement la manière dont la mémoire est accédée. Les performances supérieures observées sur le Mac Apple Silicon n’étaient pas uniquement dues à la quantité de RAM, mais dépendaient de manière critique de son Architecture Mémoire Unifiée (UMA).

Dans un système UMA, les cœurs CPU, GPU et NPU partagent tous le même pool de RAM physique et peuvent accéder aux données aux mêmes adresses mémoire simultanément. Cela élimine le besoin de copier des données entre des pools de mémoire séparés dédiés à différents processeurs (par exemple, la RAM système pour le CPU et la VRAM dédiée pour une carte graphique discrète).

Pourquoi est-ce si important pour les LLMs ?

• Efficacité : Le traitement des LLMs implique des calculs intenses sur différents types de cœurs. L’UMA permet un partage de données transparent, réduisant la latence et la surcharge associées à la duplication et au transfert de données.
• Utilisation de la Mémoire : Dans les systèmes sans UMA (comme un PC typique avec un GPU discret), les mêmes données pourraient devoir être chargées à la fois dans la RAM système principale (pour le CPU) et dans la VRAM du GPU. Cela réduit effectivement la mémoire utilisable pour le LLM lui-même.

L’implication pratique est significative. Alors que le Mac de test pouvait confortablement exécuter un modèle de 27 milliards de paramètres, quantifié à 8 bits, en utilisant 48 Go de RAM UMA partagée, atteindre des performances similaires sur un PC sans UMA pourrait nécessiter beaucoup plus de RAM totale. Par exemple, un PC avec 48 Go de RAM totale répartie en 24 Go pour le CPU et 24 Go pour le GPU pourrait n’être capable d’exécuter efficacement qu’un modèle beaucoup plus petit de 13 milliards de paramètres, en raison du partitionnement de la mémoire et de la surcharge de duplication des données.

Cet avantage architectural explique l’avance précoce que les Macs équipés de puces Apple Silicon ont prise dans l’espace de l’IA locale. Reconnaissant cela, des concurrents comme AMD ont annoncé leur gamme de SoCs Ryzen AI Max (attendue début 2025) conçue pour incorporer une approche de mémoire unifiée similaire. Au moment de ces tests, les SoCs Core Ultra d’Intel, bien qu’intégrant CPU, GPU et NPU, ne présentaient pas le même niveau d’accès mémoire entièrement unifié entre tous les types de cœurs. Cette distinction matérielle est une considération critique pour quiconque envisage sérieusement d’exécuter des LLMs plus grands et plus capables localement.

La Danse Intricate du Prompt Engineering

Amener une IA à effectuer une tâche complexe comme transformer une interview en article nécessite plus qu’un matériel puissant et un modèle capable ; cela exige une instruction sophistiquée – l’art et la science du prompt engineering. L’élaboration du prompt initial de 1 500 tokens qui guidait l’IA a été une entreprise significative.

Un point de départ utile impliquait le reverse engineering : fournir à l’IA un article complet, écrit par un humain, ainsi que sa transcription correspondante et demander quel prompt aurait dû être donné pour obtenir ce résultat. L’analyse des suggestions de l’IA sur plusieurs exemples diversifiés a aidé à identifier les éléments essentiels pour l’ensemble d’instructions.

Cependant, les suggestions de prompts générées par l’IA étaient systématiquement trop brèves et manquaient des détails nécessaires pour guider la création d’un article complet. Le vrai travail consistait à prendre ces pistes initiales fournies par l’IA et à les élaborer, en intégrant une connaissance approfondie du domaine sur la structure journalistique, le ton, le style et les considérations éthiques.

Plusieurs leçons non intuitives ont émergé :

• Clarté plutôt qu’Élégance : Étonnamment, écrire le prompt dans un style plus naturel et fluide diminuait souvent la compréhension de l’IA. Les modèles luttaient avec l’ambiguïté, en particulier les pronoms (‘il’, ‘ça’, ‘ceci’). L’approche la plus efficace consistait à sacrifier la lisibilité humaine pour la précision machine, en répétant explicitement les sujets (‘l’article devrait…’, ‘le ton de l’article doit…’, ‘l’introduction de l’article nécessite…’) pour éviter toute mauvaise interprétation potentielle.
• La Nature Évasive de la Créativité : Malgré une conception de prompt soignée visant à permettre la flexibilité, les articles générés par l’IA partageaient constamment un ‘air de famille’. Capturer l’étendue de la créativité humaine et de la variation stylistique au sein d’un seul prompt, ou même de plusieurs prompts concurrents, s’est avéré exceptionnellement difficile. La vraie variété semblait nécessiter des changements plus fondamentaux que ce que le peaufinage du prompt seul pouvait fournir.

Le prompt engineering n’est pas une tâche ponctuelle mais un processus itératif d’affinement, de test et d’incorporation de la logique métier spécifique et des nuances stylistiques. Il nécessite un mélange de compréhension technique et d’expertise approfondie du sujet.

Le Déplacement de la Charge de Travail : Décortiquer le Paradoxe de l’IA

Les expériences ont finalement conduit à une prise de conscience critique, appelée le paradoxe de l’IA : dans son état actuel, pour que l’IA puisse potentiellement alléger une partie de la charge de travail de l’utilisateur (rédiger le brouillon de l’article), l’utilisateur doit souvent investir plus de travail préliminaire.

Le problème central restait l’incapacité de l’IA à évaluer de manière fiable la pertinence au sein de la transcription brute de l’interview. Pour produire un article pertinent, fournir simplement la transcription entière était insuffisant. Une étape intermédiaire nécessaire est apparue : pré-traiter manuellement la transcription. Cela impliquait :

1. Supprimer les bavardages non pertinents, les digressions et les redondances.
2. Ajouter potentiellement des notes contextuelles (même si elles ne sont pas destinées à l’article final) pour guider la compréhension de l’IA.
3. Sélectionner soigneusement et peut-être réorganiser les segments clés.

Cette ‘curation’ de la transcription nécessite un temps et un jugement humains considérables. Le temps gagné en faisant générer un premier brouillon par l’IA était effectivement compensé, voire dépassé, par la nouvelle tâche de préparer méticuleusement ses données d’entrée. La charge de travail n’a pas disparu ; elle s’est simplement déplacée de l’écriture directe vers la préparation des données et l’affinement du prompt.

De plus, le prompt détaillé de 1 500 tokens était très spécifique à un type d’article (par exemple, une interview sur le lancement d’un produit). Couvrir la gamme diversifiée de formats d’articles qu’un journaliste produit quotidiennement – profils de startups, analyses stratégiques, couverture d’événements, enquêtes multi-sources – nécessiterait de développer, tester et maintenir un prompt distinct, tout aussi détaillé, pour chaque cas d’usage. Cela représente un investissement initial et continu substantiel en ingénierie.

Pire encore, ces expériences approfondies, s’étalant sur plus de six mois, n’ont fait qu’effleurer la surface. Elles se sont concentrées sur le scénario le plus simple : générer un article à partir d’une seule interview, souvent menée dans des cadres contrôlés comme des conférences de presse où les points de l’interviewé sont déjà quelque peu structurés. Les tâches beaucoup plus complexes, mais courantes, de synthèse d’informations provenant de multiples interviews, d’incorporation de recherches de fond, ou de gestion de conversations moins structurées sont restées inexplorées en raison de l’investissement en temps requis même pour le cas de base.

Par conséquent, bien que l’exécution locale de LLMs soit techniquement faisable et offre des avantages en termes de coût et de confidentialité des données, l’idée qu’elle permette facilement de gagner du temps ou de l’effort pour un travail intellectuel complexe comme le journalisme est, sur la base de cette enquête, illusoire à l’heure actuelle. L’effort requis se transforme simplement, se déplaçant en amont vers la préparation des données et l’ingénierie de prompts très spécifiques. Sur ces défis spécifiques – discerner la pertinence, nécessiter un pré-traitement extensif – l’IA exécutée localement a performé de manière comparable aux services en ligne payants, suggérant qu’il s’agit de limitations fondamentales de la génération actuelle de LLMs, quelle que soit la méthode de déploiement. Le chemin vers une assistance IA véritablement transparente dans de tels domaines reste complexe et exige une évolution supplémentaire tant des capacités de l’IA que de nos méthodes d’interaction avec elles.