Guillaume Orsal

Installer et utiliser Ollama : l'intelligence artificielle locale sous Linux

Guillaume Orsal — 2025-11-02T20:21:00Z

Diplômé d'un master en Intelligence Artificielle, je suis aujourd'hui développeur web fullstack spécialisé en Laravel, Livewire, React. J'intègre l'IA générative dans les projets web modernes pour créer des solutions intelligentes, sans dépendance aux API propriétaires.

Dans cet article, je vous guide pas à pas : installation d'Ollama sous Linux, choix et téléchargement de modèles open source comme Mistral ou Phi-3, tests de l'API REST et intégration dans Laravel pour bénéficier d'une IA locale rapide, économique et respectueuse de vos données.

Installation d'Ollama sous Linux

L'installation d'Ollama sous Linux (Debian/Ubuntu) est très simple grâce au script officiel fourni par l'équipe Ollama :

curl -fsSL https://ollama.com/install.sh | sh

Une fois installé, la commande ollama devient disponible et le service système démarre automatiquement. Par défaut, Ollama écoute uniquement en local sur 127.0.0.1:11434, ce qui garantit qu'aucune requête externe ne peut atteindre votre instance tant que vous ne modifiez pas la config réseau.

Pour vérifier le statut du service :

systemctl status ollama

Le service doit afficher active (running).

Vérifier l'écoute du service

Vérifier que le serveur Ollama écoute bien sur son port par défaut avec :

ss -tulpen | grep 11434

Vous devez obtenir une ligne similaire :

tcp LISTEN 0 4096 127.0.0.1:11434 ...

Cette configuration empêche toute exposition réseau accidentelle.

Si le port n'est pas visible, le service n'est probablement pas démarré ou le firewall local bloque l'accès.

Télécharger les modèles d'IA

Voici une sélection de modèles open-source adaptés à différents usages.

Ces modèles sont quantifiés (Q4/Q8), c'est-à-dire que leur précision numérique interne est réduite pour occuper moins de VRAM et calculer plus vite, tout en gardant une qualité de génération très proche du modèle d'origine.

Ollama n'embarque aucun modèle par défaut : vous devrez donc télécharger ceux dont vous avez besoin via {{ollama pull}}.

ollama pull mistral
 ollama pull phi3
 ollama pull neural-chat

Mistral : excellentes performances en génération de texte
Phi 3 : léger et performant
NeuralChat : ton conversationnel naturel

Pour lister les modèles installés :

ollama list

Premier test de génération

Vous pouvez interroger Ollama directement via son API REST locale. Par exemple, pour tester la génération avec Mistral :

curl http://127.0.0.1:11434/api/generate -d '{"model":"mistral","prompt":"Dis bonjour"}'

Ollama renvoie la réponse sous forme de tokens JSON en streaming, comme une API OpenAI.

Obtenir uniquement le texte final

jq est indispensable si vous souhaitez parser proprement les réponses JSON en ligne de commande ou dans vos scripts Bash.

L'outil s'installe avec la commande :

sudo apt-get install jq -y

Puis, un nouvel appel à l'API d'Ollama, chaîné à jq :

curl -sN http://127.0.0.1:11434/api/generate -d '{"model":"mistral","prompt":"Dis bonjour"}' | jq -rj --unbuffered 'select(.response) | .response';echo

Le texte s'affiche sans formatage JSON.

Une fonction Bash pour simplifier l'usage

Pour simplifier vos tests sans réécrire la commande curl, voici une fonction shell utilitaire à ajouter à vos alias dans .bash_aliases :

ollama-say() {
 if [ -z "$1" ]; then
 echo "Usage: ollama-say \"prompt\" [model]"
 return 1
 fi
 local PROMPT="$1"
 local MODEL="${2:-mistral}"
 curl -sN http://127.0.0.1:11434/api/generate \
 -d "{\"model\":\"$MODEL\",\"prompt\":\"$PROMPT\"}" \
 | jq -rj --unbuffered 'select(.response) | .response'
 echo
 }

Recharger les alias :

source ~/.bash_aliases

Vous pouvez maintenant appeler Ollama comme une mini-API locale directement depuis le terminal, en précisant dans la ligne de commande le prompt suivi du modèle :

ollama-say "Dis bonjour!" mistral

Après quelques secondes, vous obtiendrez la réponse sans formatage.

Accès distant via tunnel SSH

Ollama n'écoute par défaut que l'IP 127.0.0.1 pour des raisons de sécurité. Evitez absolument d'exposer le port 11434 directement sur Internet.

Si le service tourne sur une autre machine, par exemple un serveur disposant de meilleures capacités de calcul, vous pourrez créer un tunnel SSH.

Remplacez user par le login et serveur par l'IP ou le nom du serveur.

ssh -L 11434:localhost:11434 user@serveur

Le modèle devient alors accessible sur votre poste via http://localhost:11434. Le port local 11434 étant désormais redirigé vers le même port sur le serveur.

Pour lancer le tunnel SSH en arrière-plan :

ssh -N -f -L 11434:localhost:11434 user@serveur

Pour fermer le tunnel, il faudra s'attaquer directement au processus :

pkill -f "ssh -L 11434"

Cette approche permet un accès distant tout en conservant le niveau de sécurité d'un service local.

Intégration d'Ollama dans Laravel : cas d'usage concrets

L'API d'Ollama est compatible avec n'importe quel framework backend.

Ollama devient puissant lorsqu'il est intégré dans une architecture web moderne. Quelques applications concrètes :

Génération de contenu : Articles, descriptions produit, résumés
Analyse de texte : Catégorisation de commentaires, détection de spam
Suggestions intelligentes : Recommandations, auto-complétion
Recherche sémantique : Au-delà des mots-clés, recherche contextuelle via embeddings

Voici comment l'utiliser facilement dans Laravel via Http ::post() :

php
 $response = Http::post('http://localhost:11434/api/generate', [
 'model' => 'mistral',
 'prompt' => 'Génère une description produit concise pour : ' . $product->name,
 'stream' => false,
 ]);
 
 $description = $response->json()['response'];

Cela réduit drastiquement vos coûts API (OpenAI, Gemini) en gardant le contrôle total de vos données.

Performances et optimisation GPU

Bien que Ollama fonctionne sans GPU, les performances augmentent significativement avec une carte graphique supportée.

Sans GPU : 5-30 secondes par réponse selon le modèle
Avec GPU NVIDIA : Accélération de 5 à 20x, réponses en 1-5 secondes
VRAM nécessaire : Mistral ( 4GB), Phi 3 ( 2GB), Llama 2 ( 7GB)

Benchmark simple :

time ollama-say "Écris un email pour remercier un client"

En production avec une application Laravel, placer Ollama sur un serveur distinct, idéalement avec GPU, afin d'éviter de saturer votre serveur web.

Alternatives : Ollama vs llama.cpp vs LocalAI

Ollama : Installation simple, gestion facile des modèles, API REST standard. Meilleur pour débuter.

llama.cpp : Plus léger, excellente performance CPU. Idéal pour machines peu puissantes, mais installation plus complexe.

LocalAI : Interface web complète, compatible avec OpenAI API. Meilleur si vous migrez depuis OpenAI.

Pour un développeur fullstack Laravel cherchant du plug & play sans complexité, Ollama me semble le meilleur choix.

Erreurs courantes et dépannage

Ces erreurs sont les plus fréquentes lors d'un premier déploiement d'Ollama sur un serveur Linux.

Erreur « connection refused » : Ollama écoute uniquement sur localhost par défaut. Vérifier : `systemctl status ollama`. Pour l'accès distant, utiliser obligatoirement un tunnel SSH.

Modèle qui ne répond pas : Il calcule toujours. Attendre plus longtemps la première fois. Pour des timeouts, augmenter : `curl —max-time 300`.

VRAM saturée : Un modèle trop gros pour votre GPU. Vérifier : `nvidia-smi`. Réduire la taille du prompt ou utiliser un modèle plus léger.

Quantization confusion : Ollama gère automatiquement. Q4 = rapide mais moins précis, Q8 = plus lent mais meilleur. Aucune action requise sauf pour tirage manuel.

Conclusion

Ollama permet d'exécuter des modèles d'IA directement sur un serveur Linux, sans GPU obligatoire, sans dépendance tierce ni coûts récurrents.

L'installation est rapide, la configuration sûre, et la flexibilité excellente pour le développement, les tests et et la génération de contenu automatisée.

Une solution robuste et respectueuse des données, idéale pour développeurs et passionnés d'IA locale.

Ollama s'intègre parfaitement dans un workflow moderne Laravel/Livewire/React, que ce soit pour prototyper en local, automatiser des tâches éditoriales ou alimenter une plateforme SaaS interne.

Intégrer Ollama à votre stack full-stack : expertise et services

Intégrer Ollama dans une architecture web (Laravel, React, Livewire, Tailwind) demande une bonne compréhension du code métier, du traitement de texte génératif et des flux applicatifs.

Si vous envisagez d'ajouter de l'IA générative locale à votre application, je peux vous accompagner sur :

Intégration Laravel / API : prompts, streaming, validation, performances
Automatisation & file de jobs : tâches lourdes, exécution asynchrone
Choix et gestion des modèles : Mistral, Phi-3, formats d'entrée/sortie
Déploiement sur serveur Linux : installation, configuration et supervision de base

Je suis développeur web fullstack spécialisé Laravel et IA générative locale, avec une solide pratique Linux. Mon objectif : livrer des solutions fonctionnelles, maintenables et utilement assistées par l'IA.

Parlons de votre projet

SAS : Exécution automatique d'un script

Guillaume Orsal — 2011-01-28T16:59:51Z

Lorsque vous faites du développement sous SAS, et que votre programme est enfin rodé, vous allez vouloir faire en sorte qu'il s'exécute automatiquement, d'un simple clic. Voici une petite solution, via un batch windows, et quelques adaptations à vos scripts.

Le batch

Le programme complet est en pièce jointe. Nous allons voir étape par étape son fonctionnement. Pour le créer, le bloc-notes de windows est suffisant et il suffit de modifier l'extension du fichier une fois enregistrer en .bat

On commence par changer de répertoire pour se placer dans le répertoire de travail de SAS.

echo Changement de repertoire vers SAS
 pushd "C:\Document\My SAS Files\9.1"

On lance l'éxécution de SAS avec les bons paramètres :

Adapter l'emplacement du programme sas.exe à votre configuration en fonction de là où vous l'avez installé.
CONFIG permet de spécifier l'emplacement du fichier de configuration de votre environnement. Pour le trouver, regarder les propriétés de l'icone qui vous permet de lancer SAS habituellement, dans le champ cible, le fichier CFG doit être indiqué.
SYSIN permet d'indiquer le nom et l'emplacement du programme SAS à exécuter.
ICON permet d'exécuter SAS dans une fenêtre réduite.
LOG permet de spécifier le fichier de log, il recueillera ce qui apparait en temps normal dans la fenêtre journal.

echo Lancement de SAS
 "C:\Program Files\SAS\SAS 9.1\sas.exe" -CONFIG "C:\Program Files\SAS\SAS 9.1\nls\fr\SASV9.CFG" -sysin "C:\MonEtude\MonProg.sas" -icon -log "C:\MonEtude\MonProg.log"

Si vous avez suivi mon article sur la détection de la bonne connexion au serveur SAS, vous pouvez intégrer ici la détection dans le log du résultat du Test. Cela permet de savoir si le programme SAS a pu s'exécuter normalement.

Pour cela, j'utilise grep. Pour ceux qui ne connaitrait pas, c'est un petit utilitaire qui provient du monde unix de recherche dans des fichiers. Et heureusement cela a été porté sous windows, ici : gnuwin32.sourceforge.net

Vous pourrez rafiner la détection en fonction de vos besoins, par exemple en recherchant la présence de warning dans le log. Ici, je recherche donc la ligne qui porte le résultat de mon test de connexion serveur. En fonction du résultat, il faudra peut-être que j'exécute à nouveau ma procédure.

Le fait d'exécuter tout le programme d'une seule traite, vous oblige, lors de la conception et de l'ordonnancement des étapes, à faire un développement plutôt sécurisé, qui valide bien chaque étape, s'auto-vérifie, et préfère ne rien faire plutôt que de faire une mauvaise étape. Car bien évidemment vous n'avez plus la sécurité proposé par l'exécution étape par étape que vous pouvez pratiquer lorsque vous êtes en mode interactif. Car rappelez-vous, en cas d'erreur, SAS a tendance à continuer son traitement, même avec des données incomplètes.

echo Recherche etat du serveur
 grep "Connexion au serveur SAS" "C:\MonEtude\MonProg.log"

Il ne reste plus qu'à terminer le batch, retour à l'emplacement de départ via popd, et une pause afin que la fenêtre ne se ferme pas immédiatement à la fin de l'exécution, que l'on puisse surveiller le résultat.

echo Retour au repertoire de lancement
 echo Fin du traitement : %DATE% %TIME%
 popd
 pause
 exit /B

Le script

Comme je l'ai évoqué un peu plus tôt il y a quelques éléments à apporter à votre script SAS pour que tout fonctionne correctement.

Je passe les détails sur l'export des résultats : prévoyez des déposes sur serveur ou des envois par mail.

Par contre une première étape importante, lorsque vous ouvrez une session normale c'est l'identification auprès du serveur SAS, dans le cas ou vous n'avez pas une installation mono-poste. Il faudra adapter votre autoexec.sas pour qu'il vous identifie automatiquement. Plus précisément d'ailleurs, cela se passe dans le script d'ouverture de session.

Dernière petite recommandation : n'oubliez pas d'inclure un « signoff ;signoff; » à la fin de votre programme SAS s'il utilise une connexion serveur. Sinon le programme ne terminera pas, ou ne le fera pas « proprement ». De plus, je vous conseille de doubler la commande, cela fonctionne mieux, mais ne me demander pas pourquoi.

Voilà. En adaptant les emplacements, et en plaçant ce fichier dans le répertoire de votre programme SAS cela devrait fonctionner sans problème.

SAS : Détection de connexion serveur

Guillaume Orsal — 2010-01-04T17:16:34Z

Pour des raisons professionnelles, j'utilise régulièrement l'outil de statistiques SAS, en mode client-serveur. Mais trop souvent la connexion au serveur, automatisée à l'ouverture de l'application ne fonctionne pas. Je souhaitais donc avoir un moyen de déterminer automatiquement si la connexion était établie, pour sécuriser la suite des traitements.

Je m'en suis ouvert au spécialiste SAS de la société qui m'a dit que ce n'était pas possible de détecter la connexion, même avec le langage macro. Je ne me suis pas laissé abattre, et j'ai cherché une solution. Après quelques recherches dans l'aide mal conçue de l'application, j'ai enfin trouvé.

J'ai eu l'idée toute simple que tester la connexion au serveur, revenait à vérifier l'existence de tables des librairies distantes (une base de donnée SAS). Il n'y avait qu'à trouver la macro fonction %exists.

En toute fin de mon autoexec.sas (le programme exécuté à l'ouverture d'une session SAS), donc après que les associations aux librairies aient été effectuées, j'ai ajouté le bout de code suivant.

Test global

%macro Test_Connexion_Serveur();
 
 /* Déclaration de la variable résultat comme globale */
 /* pour faciliter sa réutilisation ultérieure */
 %global Connexion_Serveur ;
 
 /* Initialisation de la variable résultat */
 %let Connexion_Serveur = OK ;
 
 /* Test de la non existence d'une table de ma 1ère librairie */
 %if not( %sysfunc( exist( Librairie1.MaTable ) ) )
 %then %let Connexion_Serveur = KO ;
 
 /* Test de la non existence d'une table de ma 2ème librairie */
 %if not( %sysfunc( exist( Librairie2.UneAutreTable ) ) )
 %then %let Connexion_Serveur = KO ;
 
 /* Affichage du résultat du test */
 %put Connexion au serveur SAS : &Connexion_Serveur ;
 
 %mend Test_Connexion_Serveur;
 
 /* Appel de ma fonction */
 %Test_Connexion_Serveur;

J'ai affecté le résultat à une variable globale afin de pouvoir l'utiliser dans un script si nécessaire.

Dans mon cas, seul m'intéressait d'afficher le résultat global dans la fenêtre journal. Mais on pourrait sans problème ajouter une fonction pour avoir un résultat plus détaillé, qui indiquerait quelles sont les librairies en erreur. Ce qui donnerait quelque chose comme suit.

Test détaillé

%macro Test_Connexion_Serveur();
 
 %global Connexion_Serveur ;
 %let Connexion_Serveur = OK ;
 
 /* Test de la non existence d'une table de ma première librairie */
 %if not( %sysfunc( exist( Librairie1.MaTable ) ) ) %then %do ;
 
 /* Si non trouvée, alors modification de la variable résultat */
 %let Connexion_Serveur = KO ;
 
 /* Affichage de la librairie en anomalie */
 %put Pb accès librairie : Librairie 1;
 
 %end ;
 
 /* Test de la non existence d'une table de ma seconde librairie */
 %if not( %sysfunc( exist( Librairie2.UneAutreTable ) ) ) %then %do ;
 %let Connexion_Serveur = KO ;
 %put Pb accès librairie : Librairie 2;
 %end ;
 
 %put Connexion au serveur SAS : &Connexion_Serveur ;
 
 %mend Test_Connexion_Serveur;
 
 %Test_Connexion_Serveur;

Enfin, on pourrait imaginer que ce soit le script SAS qui va s'exécuter ensuite qui fasse tout seul appel à la fonction, pour ne tester que les librairies dont il a besoin. Dans mon cas, j'utilise trop souvent les mêmes librairies pour que cela présente un intérêt, mais cela pourrait servir à quelqu'un. Cela donnerait quelque chose comme cela.

Test à la demande

/* Déclaration de la variable résultat comme */
 /* globale pour faciliter sa réutilisation ultérieure */
 %global Connexion_Serveur ;
 
 /* Initialisation de la variable résultat */
 %let Connexion_Serveur = OK ;
 
 %macro Test_Connexion_Serveur( LibrairireATester );
 /* En fonction de la librairie à tester */
 %if ( &LibrairieATester=Librairie1 ) %then %do ;
 %if not( %sysfunc( exist( Librairie1.MaTable ) ) ) %then %do ;
 %let Connexion_Serveur = KO ;
 %put Pb accès librairie : &LibrairieATester;
 %end ; %else %do ;
 %put Connexion à la librairie &LibrairieATester : OK; 
 %end ;
 %end ;
 
 %if ( &LibrairieATester=Librairie2 ) %then %do ;
 %if not( %sysfunc( exist( Librairie2.MaTable ) ) ) %then %do ;
 %let Connexion_Serveur = KO ;
 %put Pb accès librairie : &LibrairieATester;
 %end ; %else %do ;
 %put Connexion à la librairie &LibrairieATester : OK; 
 %end ;
 %end ;
 
 /* Si aucun paramètre on affiche un peu d'aide */
 %if ( %length(&LibrairieATester) = 0 ) %then %do;
 %put Liste des paramètres : Librairie1, Librairie2 ;
 %end;
 
 %mend Test_Connexion_Serveur;
 
 /* Appel de ma fonction */
 %Test_Connexion_Serveur() ;
 %Test_Connexion_Serveur( Librairie1 ) ;
 %Test_Connexion_Serveur( Librairie2 ) ;
 %Put Connexion au serveur : &Connexion_Serveur;

Le dernier exemple est parfaitement simplifiable, car la structure de test se répète autant de fois qu'on a de librairies. Vous ferez également attention dans le chemin des librairies à utiliser. En effet, ces macros doivent s'exécuter en local puisque c'est pour tester la connexion serveur et donc on n'est pas sur d'être connecté. Par contre, il faut utiliser le chemin d'accès local aux librairies distantes, sinon la macro ne trouvera jamais rien. Dans l'exemple ci-dessous, cela correspond au Lib1_dst, le nom de la librairie défini en local.

RSubmit ;
 LibName Lib1 "/Monchemin/SurMaLibrairie";
 EndRSbumit ;
 LibName Lib1_Dst SLibRef=Lib1 Server=MonServeur;

Evidemment tout ceci ne fonctionne qu'avec des tables dont on est sûr de l'existence.

Voilà. Je vous explique bientôt, comme j'ai ensuite réussi à automatiser l'exécution des scripts, tout en sécurisant mon traitement, puisque je peux désormais m'assurer que les accès fonctionnent, ce qui limite fortement le risque d'anomalie en sortie.