CyberSDF

Reprenez la main sur votre numérique

IA pratique : choisir une approche selon votre besoin

Microprocesseur carré entouré de pistes cuivrées sur un circuit imprimé vert.

Pour choisir un premier usage de l’intelligence artificielle, commencez par le résultat attendu, puis demandez où vont les données et comment vous contrôlerez la sortie. Gardez le traitement sur votre machine ? Choisissez une IA locale. Besoin d’un texte fiable ? Vérifiez la réponse. Besoin d’un visuel utile ? Générez-le puis inspectez le fichier. Besoin d’essayer un moteur ? Installez Ollama dans un dossier borné.

Sommaire
  1. Le bon résultat avant le bon outil
  2. Les quatre questions qui orientent le choix
  3. Garder le traitement près de soi
  4. Quand une réponse demande une preuve
  5. Une image doit apporter une information
  6. Installer seulement après la décision
  7. Lire les résultats sans surinterpréter

Le choix ne porte donc pas d’abord sur un outil IA, un modèle IA ou une marque. Il porte sur une tâche, les données qu’elle engage, le lieu du calcul et le contrôle qui arrête la chaîne quand le résultat ne convient pas.

Le bon résultat avant le bon outil

Une demande comme "je veux utiliser l’IA" ne permet aucune décision. Remplacez-la par un résultat visible : un brouillon à relire, une réponse à documenter, un fichier image à intégrer, ou une installation locale à mesurer. Le résultat attendu donne aussi le critère d’arrêt. Un texte peut être refusé parce qu’une affirmation n’a pas de source ; une image parce que ses dimensions ne conviennent pas ; un moteur parce que son débit rend l’usage impossible.

Notez ensuite les données qui entreront dans le traitement. Un document personnel, une information confidentielle et une question générale n’ont pas le même chemin acceptable. Le lieu du calcul vient juste après : une application installée n’est pas nécessairement un calcul local, et un service distant n’est pas rendu local par son interface de bureau. Enfin, prévoyez une observation : source ouverte, version, code retour, dimension de fichier ou temps de production.

Cette préparation évite de confondre une sortie convaincante avec une sortie utilisable. Une réponse peut être grammaticalement parfaite et rester non sourcée. Une installation peut répondre à une commande et rester trop lente. Une image peut respecter un objet demandé et rater le format. Le bon premier choix rend le résultat et son refus mesurables.

Les quatre questions qui orientent le choix

Répondez à ces questions avant d’ouvrir un outil. Elles donnent une première destination sans prétendre choisir à votre place.

Si votre question principale est… Votre première action Ce que vous devez obtenir
Les données doivent-elles rester sur ma machine ? examiner le chemin du calcul local un test hors connexion et un lieu de traitement identifié
La réponse contient-elle un fait que je vais réutiliser ? isoler les affirmations et leurs sources une version, une date, une portée et un statut pour chaque fait
L’image doit-elle transmettre une information ? définir sa fonction puis contrôler le fichier reçu un visuel qui apporte quelque chose au texte dans le format prévu
Ai-je décidé que le calcul local est le bon choix ? installer un petit moteur dans un espace réversible une version, une sortie, un débit et une procédure de nettoyage

Le tableau ne classe pas les outils : il classe les décisions à prendre avant leur usage. Si deux questions semblent prioritaires, commencez par celle qui peut exposer une donnée ou engager le plus de temps.

Garder le traitement près de soi

Le mot "local" décrit le chemin des données au moment du traitement, pas l’endroit où l’application est installée. Pour parler de traitement local, vérifiez que le calcul se fait sur votre machine, qu’une question peut être traitée sans réseau après téléchargement et que le prompt comme la réponse ne partent pas vers un service tiers.

Le test le plus parlant consiste à télécharger le modèle IA, couper l’accès réseau, puis poser une question courte. Une réponse qui arrive ne suffit pas à décrire toute la configuration, mais une erreur de connexion révèle qu’une partie du service dépend encore d’un serveur distant. La commande de suivi doit aussi montrer le processeur ou la carte graphique réellement utilisés. Un nom de modèle comportant "local" ne remplace pas ces observations.

Pour sélectionner un outil IA local sans confondre application installée et calcul réellement local, commencez par choisir une IA locale selon la tâche et la mémoire disponible. Cette méthode distingue les recommandations d’un éditeur des mesures faites sur une machine réelle, puis propose un ordre de décision qui survit aux changements de version.

La question à retenir est simple : un traitement local se vérifie par le lieu du calcul et le chemin des données, pas par l’icône du logiciel.

Quand une réponse demande une preuve

Une réponse générée devient une matière à vérifier dès qu’elle contient un chiffre, une date, une citation, une commande ou une recommandation que vous comptez transmettre. Découpez-la en affirmations unitaires. Pour chacune, cherchez le document d’origine, lisez le passage dans son contexte et contrôlez la date, la version et le périmètre. Une phrase qui mélange deux faits doit recevoir deux contrôles.

Une IA peut produire une affirmation fausse avec un ton assuré, une citation plausible ou une étape de raisonnement qui semble cohérente. Le ton ne permet pas de trancher : ouvrez la source annoncée, comparez le passage avec la phrase et vérifiez la version ainsi que le périmètre. Si la source n’existe pas, la phrase reste une hypothèse à tester ou à retirer.

Une source retrouvée ne suffit pas non plus. Elle doit dire le fait qu’on lui attribue, dans la version qui concerne la question. Si le document n’existe pas, marquez l’affirmation comme non sourcée. Si elle peut être reproduite, définissez un environnement et un résultat attendu, puis gardez la sortie avec sa date. La méthode pour vérifier une réponse IA avant de la réutiliser détaille chaque contrôle et montre comment décider lorsqu’une source manque.

Une réponse fluide est une hypothèse tant que sa source et sa portée n’ont pas été contrôlées.

Une image doit apporter une information

Une image utile remplit une fonction identifiable : elle situe un lieu, montre un objet ou une matière décrite, ou rend visible une relation que le texte ne peut pas montrer aussi vite. Si elle ne fait qu’occuper un espace, elle ajoute du poids sans aider la lecture. Décidez d’abord ce que le lecteur doit comprendre en la regardant.

La demande doit alors préciser l’objet, les matières, la lumière, le cadrage et les éléments à contrôler. Un prompt n’est pas une preuve de conformité. Mesurez le fichier reçu : dimensions, format, poids et présence éventuelle de texte ou de marques. Une capture d’écran, un message d’erreur ou un résultat chiffré ne se simule pas avec une image générée, car le visuel deviendrait une fausse pièce de preuve.

Dans l’essai publié le 15 septembre 2026, le paysage demandé mesurait 1536 x 1024 pixels, tandis que le PNG reçu mesurait 1024 x 1536 pixels et pesait 2 208 701 octets. Ce seul écart de dimensions suffisait à refuser le fichier avant les autres observations. Le cas complet pour générer une image avec IA et la juger conserve la demande utilisée, le fichier reçu et les défauts constatés.

Le fichier reçu tranche la conformité d’une image, jamais le prompt seul.

Installer seulement après la décision

L’installation est une conséquence du besoin local, pas une preuve qu’il était le bon. Avant de télécharger un moteur, fixez la tâche, la taille de réponse acceptable, la mémoire disponible et le délai que vous tolérez. Une voie réversible dans un dossier utilisateur permet d’observer sans modifier le système, puis de supprimer le dossier si le résultat ne convient pas.

L’essai publié le 15 septembre 2026 porte sur Ollama 0.34.0 sous Linux x86_64, sans carte graphique, avec douze processeurs virtuels. Le paquet mesurait 1 433 537 033 octets compressés et 2,2 Go une fois extrait. Le petit modèle qwen2.5:0.5b occupait 397 Mo sur disque et 484 Mo chargé. Ces mesures répondent à une question concrète : quelle place et quel délai cette voie impose-t-elle sur cette machine ?

Le même essai a produit 12 jetons en 25,9 secondes, soit environ 0,46 jeton par seconde. La chaîne technique fonctionnait, mais la réponse en français comportait une répétition fautive. Ce résultat sépare deux critères qui sont souvent mélangés : un serveur peut répondre correctement et le modèle peut rester inadapté à la tâche. Les commandes pour installer Ollama sous Linux couvrent la vérification de version, la mesure et le nettoyage dans un espace borné.

Une installation qui répond ne prouve pas que la sortie répond au besoin.

Lire les résultats sans surinterpréter

Chaque résultat doit rester attaché à son contexte. Un débit dépend du modèle, du nombre de jetons, de la mémoire, du processeur et de la version. Une dimension d’image dépend de l’appel et du fichier réellement écrit. Une affirmation dépend du document, de sa date et de son champ d’application. Retirer ces attaches transforme une observation utile en promesse générale.

Séparez aussi le fonctionnement de la qualité. Le serveur Ollama observé a démarré et a répondu ; sa sortie courte en français contenait pourtant une répétition et une explication approximative. De la même manière, le rendu d’image observé contenait un objet conforme à la demande mais ne respectait pas le format et portait des marques de lettrage illisibles. La réussite de l’appel ne valait donc pas validation du résultat.

Pour une réponse, notez au minimum le texte contrôlé, la source, sa date, la version concernée et la portée. Pour une commande, gardez l’environnement, l’entrée, la sortie et le code retour. Pour une image, conservez la demande, le fichier, ses dimensions et les défauts qui ont motivé la décision. Ces traces ne remplacent pas le jugement, mais elles empêchent de confondre un cas observé avec une règle.

Une mesure n’est utile que si son entrée, sa sortie, sa version et sa date restent attachées au chiffre.

Dans cette rubrique