Tutoriel | Héberger son IA locale avec Ollama et lui apprendre vos données (RAG) sans exploser son serveur !

Salut à tous !

Aujourd’hui, on va s’attaquer à un gros morceau, mais on va le faire à notre sauce d’admin sys : proprement, en local, et sans dépendre du cloud.

Vous en avez marre d’entendre parler d’IA tout en sachant que la moindre question posée à ChatGPT envoie vos données internes, vos docs techniques ou les infos de votre boîte directement sur des serveurs aux États-Unis ? Moi aussi.

La bonne nouvelle, c’est qu’héberger son propre LLM (Large Language Model) n’est plus réservé à ceux qui ont 15 000 € à mettre dans un cluster de GPU. Aujourd’hui, on va voir comment déployer Ollama sur une simple VM Linux (un petit 4 vCPUs / 16 Go de RAM fera l’affaire), et surtout, on va voir comment lui injecter vos propres données grâce à la magie du RAG (Retrieval-Augmented Generation).

Accrochez vos ceintures, on va se monter un chatbot souverain et ultra-léger !

1. Ollama : Le « Docker » des modèles d’IA

Si vous savez utiliser Docker, vous savez utiliser Ollama. C’est un outil écrit en Go qui simplifie à l’extrême le téléchargement et l’exécution de modèles d’IA en local. Il gère la RAM, le CPU, et expose même une API REST compatible avec celle d’OpenAI. Que demander de plus ?

Installation

Sur votre distribution Linux préférée (Debian, Ubuntu…), l’installation se fait via un script officiel. Oui, je sais, on n’aime pas trop les curl | bash, mais ici c’est l’outil officiel et il configure tout le service systemd proprement.

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

 

Vérifions que le démon tourne correctement :

systemctl status ollama

 

Télécharger et lancer un modèle

Pour notre VM sans carte graphique, on va éviter les modèles obèses à 70 milliards de paramètres. On va partir sur Gemma 3 (1B) Il est  bluffant et tourne parfaitement sur CPU.

# On télécharge et on lance le modèle interactif
ollama run gemma3:1b

 

Boum ! Vous avez un prompt interactif. Vous discutez avec une IA qui tourne à 100% sur votre machine. Pour sortir, faites un petit /bye.

Par défaut, Ollama écoute sur le port 11434 en local. Vous pouvez tester son API avec un simple curl :

curl http://localhost:11434/api/generate -d '{ "model": "gemma3:1b", "prompt": "Explique-moi ce qu'est un hyperviseur en une phrase.", "stream": false }'

C’est cool, mais ce modèle a un défaut : il ne connaît rien de VOUS. Il ne connaît pas vos procédures internes, ni votre wiki, ni les tarifs de votre boîte. C’est là qu’entre en jeu le RAG.

 

2. Le RAG : Donner un cerveau métier à votre IA

Plutôt que d’essayer de ré-entraîner le modèle avec vos données (le fameux fine-tuning, qui coûte un bras en puissance de calcul et qui est une galère à maintenir), on utilise le RAG (Retrieval-Augmented Generation).

Le concept est brillant de simplicité :

  1. On découpe vos documents (fichiers TXT, PDF, Markdown) en petits morceaux.

  2. On transforme ces morceaux en vecteurs (une suite de chiffres) et on les stocke dans une petite base de données.

  3. Quand l’utilisateur pose une question, on cherche les morceaux de vos documents qui s’en rapprochent le plus.

  4. On envoie ces morceaux à Ollama en lui disant : « Voici des infos de mon wiki interne. Utilise-les pour répondre à cette question : … »

C’est l’équivalent de donner un livre ouvert à un étudiant pendant un examen.

3. Pratique : Le script RAG « Admin-Friendly » (Ultra-Light)

Beaucoup de tutos vous diront d’installer l’usine à gaz LangChain ou le monstrueux PyTorch (qui va vous bouffer 4 Go d’espace disque). Sur Journal d’un admin Linux, on aime quand c’est slim.

On va écrire un script Python qui n’utilise que l’API de notre serveur Ollama (pour la génération ET pour la vectorisation) et une minuscule base de données appelée ChromaDB.

Les prérequis

Sur votre machine, on télécharge un modèle spécialisé d’Ollama (minuscule et ultra-rapide) pour créer nos vecteurs :

ollama pull nomic-embed-text

 

Puis on installe les deux seules dépendances Python nécessaires :

pip3 install requests chromadb

 

Vos données

Créez un fichier wiki_interne.txt avec quelques infos factices pour le test :

Serveur d’impression : L’IP du serveur d’impression de l’étage 2 est 192.168.1.50. Il faut utiliser le driver générique PCL6.
VPN : Pour se connecter au VPN de l’entreprise, le port utilisé est le 1194 en UDP. Le certificat doit être renouvelé tous les ans.
Serveur Web : Notre site principal tourne sous Nginx sur le serveur SRV-WEB-01 (Debian 12).

Le Script Python : rag_local.py

Voici notre script fait maison. Il est agnostique, rapide, et ne fait pas exploser la RAM.

import requests
import chromadb
import argparse

# --- CONFIGURATION ---
URL_OLLAMA = "http://localhost:11434"
MODEL_IA = "gemma3:1b"          # Modèle qui rédige la réponse
MODEL_VECTEUR = "nomic-embed-text" # Modèle qui lit le document

def get_embedding(text):
    """ Demande à Ollama de transformer le texte en suite de nombres (vecteurs) """
    res = requests.post(f"{URL_OLLAMA}/api/embeddings", 
                        json={"model": MODEL_VECTEUR, "prompt": text})
    return res.json()["embedding"]

def interroger_mon_ia(question, fichier_txt):
    try:
        # 1. On charge notre fichier de doc interne
        with open(fichier_txt, 'r', encoding='utf-8') as f:
            contenu = f.read()
        
        # On découpe grossièrement par paragraphes
        paragraphes = [p.strip() for p in contenu.split('\n') if len(p.strip()) > 10]

        # 2. Création de notre base de données vectorielle (en RAM pour la vitesse)
        db_client = chromadb.Client()
        collection = db_client.get_or_create_collection(name="mon_wiki")

        # 3. On injecte nos paragraphes dans la base via Ollama
        print(f"[*] Indexation de {len(paragraphes)} blocs de texte en cours...")
        for i, texte in enumerate(paragraphes):
            vecteur = get_embedding(texte)
            collection.add(ids=[str(i)], embeddings=[vecteur], documents=[texte])

        # 4. Recherche magique : on trouve les infos liées à la question !
        vecteur_question = get_embedding(question)
        resultats = collection.query(query_embeddings=[vecteur_question], n_results=1)
        contexte_trouve = "\n".join(resultats['documents'][0])

        # 5. On demande à l'IA de faire une synthèse avec NOS infos
        prompt = (
            f"Tu es un admin sys expert. Utilise UNIQUEMENT le contexte ci-dessous pour répondre.\n"
            f"CONTEXTE INTERNE :\n{contexte_trouve}\n\n"
            f"QUESTION : {question}\n\n"
            f"RÉPONSE :"
        )

        res_ia = requests.post(f"{URL_OLLAMA}/api/generate", 
                               json={"model": MODEL_IA, "prompt": prompt, "stream": False})
        
        return res_ia.json().get('response', 'Erreur de génération')

    except Exception as e:
        return f"Erreur critique : {str(e)}"

# --- EXÉCUTION ---
if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Interrogez vos docs locales avec l'IA")
    parser.add_argument("question", type=str, help="Votre question")
    parser.add_argument("-f", "--fichier", type=str, default="wiki_interne.txt", help="Fichier source")
    args = parser.parse_args()

    reponse = interroger_mon_ia(args.question, args.fichier)
    print(f"\n[RÉPONSE DE L'IA] :\n{reponse}")

Il ne reste plus qu’à poser une question ultra-spécifique à notre script depuis le terminal :

python3 rag_local.py "Sur quel port tourne notre VPN ?"

Sortie :

[*] Indexation de 3 blocs de texte en cours...

[RÉPONSE DE L'IA] :
1194 en UDP !

💥 Bim ! L’IA ne vous a pas fait une réponse générique copiée sur Wikipédia, elle a lu votre fichier de configuration et vous a répondu avec vos données. Le tout sans qu’un seul octet n’ait quitté votre serveur en bare-metal ou votre VM.

Conclusion

L’association d’Ollama (pour l’inférence) et d’un petit script Python avec ChromaDB (pour le RAG) est une véritable tuerie. C’est robuste, ça consomme peu de ressources disque par rapport aux grosses stacks d’IA habituelles, et ça ouvre la porte à des dizaines d’usages :

  • Un chatbot d’entreprise qui interroge vos logs ou vos manuels de procédures.

  • Une API (en rajoutant un peu de FastAPI par dessus) pour le support IT interne.

  • Une solution d’IA à proposer à vos clients, sans les soucis liés au RGPD !

Et vous, vous l’hébergez où votre IA ? Dites-le-moi en commentaire ou venez en discuter avec nous sur le réseau !




Tutoriel | Dokploy : Le PaaS qui veut réconcilier l’Admin Linux avec le déploiement moderne

Article publié le 19 Janvier 2026

 

À l’heure où les notions de cloud souverain et d’écosystème « Auto-hébergé » reviennent en force, utiliser Dokploy sur votre infrastructure « on-premise » devient de plus en plus pertinent.

Dokploy est une solution open source qui permet de déployer en 10 minutes un PaaS sur des serveurs classiques, qu’ils soient sur votre cloud privé ou chez un cloud provider public (AWS, GCP ou Azure).

 

1) Installation

Pour ce tuto, j’ai utilisé une VM sous Debian 12 avec 4 vCPU et 16 Go de RAM afin d’être peinard.

L’installation est une formalité, même pour un admin débutant. Il suffit d’exécuter ce script avec l’utilisateur root :

sudo curl -sSL https://dokploy.com/install.sh | sh

 

Que fait ce script?

  • Vérification des dépendances : Il installe curl, sudo et git.

  • Setup Docker : S’il n’est pas présent, il installe Docker Engine.

  • Swarm Mode : Il exécute docker swarm init (si ce n’est pas déjà fait). C’est crucial car Dokploy utilise les services Swarm pour la gestion du réseau. (Même si je ne suis pas fan de Docker Swam il faut admettre que c’est bien pratique)

  • Pull & Run : Il télécharge l’image Docker de Dokploy et lance le service.

Une fois terminé, vérifiez que l’interface web est dispo sur le port 3000 et enregistrez votre premier utilisateur.

 

Sous le capot, un petit docker ps -a vous confirmera que tout tourne proprement.

 

2) Prise en main

Nous voici sur l’interface d’admin qui me parait fort sympathique. On est loin des usines à gaz surchargées : ici, c’est propre, sombre (le mode Dark par défaut, merci pour nos yeux d’admin) et surtout très structuré.

Voici ce qu’on retrouve dans la barre latérale et qui va devenir notre quotidien :

Le pilotage opérationnel (Home)

C’est ici que l’on gère le « Run ».

  • Projects : C’est le cœur du réacteur. On y crée des groupes pour nos apps (par exemple « Prod », « Staging » ou « Blog »).

  • Monitoring & Schedules : Pour garder un œil sur la charge CPU/RAM et gérer les tâches cron sans avoir à éditer la crontab du host à la main.

  • Traefik File System & Docker/Swarm : La partie que j’apprécie particulièrement. Dokploy ne vous cache rien. Vous avez un accès direct aux fichiers de config du reverse proxy et à l’état de votre cluster Swarm. C’est transparent.

La configuration fine (Settings)

C’est là qu’on sent que l’outil est pensé pour la prod « on-premise » :

  • Remote Servers & Cluster : Dokploy n’est pas limité à un seul nœud. On peut piloter d’autres serveurs et gérer son cluster directement depuis cette interface.

  • Registry & S3 Destinations : Indispensable ! On peut lier son propre registre Docker et surtout configurer ses backups de bases de données vers du S3 (AWS, Minio ou autre).

  • Certificates : La gestion du SSL (Let’s Encrypt) est automatisée, mais vous pouvez aussi importer vos propres certificats si vous avez des contraintes de sécurité spécifiques.

Le petit plus : L’onglet AI

On notera la présence d’un menu AI. À l’heure actuelle, cela permet de configurer un modèle (type OpenAI) pour vous aider à générer des Dockerfiles ou des fichiers de configuration si vous avez un trou de mémoire sur une syntaxe. Gadget pour certains, gain de temps pour d’autres.

3) Déploiement d’un workload.

On va maintenant déployer un site wordpress via Dokploy pour voir comment tout cela fonctionne:

3.1) Déploiement de la base de données

– Créons un projet en cliquant sur « Create Project » depuis l’onglet « Projects »:

– Une fois le projet créé, nous allons déployer ce dont nous avons besoin pour faire tourner un site wordpress: une application et une database

– Commencons pas la base de donnée: cliquez sur « service » et « database. »

Comme vous pouvez le voir, l’éventail de choix est large ; pour ce tuto, nous partons sur une base MySQL. Remplissez simplement les champs de configuration et validez en cliquant sur « Create ».

 

Il ne reste plus qu’à déployer la base de données en cliquant sur le bouton « Deploy »

C’est beau!!

En vérifiant on peut peut voir que le container est bien démarré (1er ligne)

 

3.) Déploiement de WordPress

Ca repart, on crée un nouveau service de type application que l’on va nommer « website »:

On clique sur le service que l’on vient de créer pour le configurer :

Arrétons nous un instant pour rentrer dans le détail de cette interface de configuration:

C’est ici que la magie du PaaS opère. Une fois votre projet créé (ici je l’ai nommé « WordPress »), on rentre dans le vif du sujet avec la configuration de notre service. L’interface de déploiement est un modèle du genre : complète mais sans fioritures.

Le pilotage du déploiement

En haut de page, on retrouve nos commandes de vol habituelles : Deploy, Reload, Rebuild ou encore Start. Mention spéciale pour le bouton Open Terminal qui permet de garder un pied dans le conteneur sans quitter son navigateur. On peut aussi activer l’Autodeploy pour que chaque push sur votre branche déclenche la mise à jour, ou forcer un Clean Cache si vous avez des doutes sur votre build.

Le choix de la source (Provider)

Dokploy est très souple sur l’origine du code :

  • Git pur jus : Intégration directe avec GitHub, GitLab, Bitbucket ou même une instance Gitea auto-hébergée (cohérent avec notre approche souveraine).

  • Docker : Vous pouvez aussi simplement tirer une image depuis un registre Docker.

  • Drop : Pour les plus pressés, on peut même envoyer directement un fichier.

La cuisine interne : Build Type

C’est là que l’admin va pouvoir choisir sa méthode préférée pour transformer le code en conteneur :

  • Dockerfile : Pour ceux qui aiment garder le contrôle total sur leur image.

  • Nixpacks (par défaut) : C’est l’option moderne qui analyse votre code et crée l’image optimale tout seul.

  • Heroku/Paketo Buildpacks : Pour rester compatible avec les standards du marché.

Petit conseil d’admin : Comme indiqué par l’alerte dans l’interface, le build peut être gourmand en ressources (CPU/RAM). Avec mes 16Go de RAM, je suis large, mais gardez un œil sur vos petites instances lors des phases de compilation.

On retrouve également des onglets cruciaux pour la prod : Environment pour vos variables secrètes, Domains pour le mapping DNS avec SSL automatique, et Volume Backups pour ne pas oublier que la donnée, c’est sacré.

 

Pour notre usecase nous allons déployer une image wordpress depuis le docker hub, pour cela cliquez sur le provider Docker:

Faisons un petit tour dans l’onglet environnement pour renseigner les informations de connexions à la base de donnée que nous venons de créer juste avant (cliquez sur le petit oeil en haut à droite pour activer le mode édition):

Cliquez sur « save »

L’astuce de sioux : Accéder au site sans DNS avec sslip.io

C’est le moment où l’admin a fini sa conf et veut voir le résultat, mais n’a pas forcément envie d’aller modifier ses zones DNS chez son registrar pour un simple test.

C’est là qu’intervient sslip.io. Pour ceux qui ne connaissent pas, c’est un service de « DNS Wildcard » génial : il résout n’importe quel nom de domaine contenant une adresse IP vers cette même adresse IP.

  • Si vous tapez 13.42.26.29.sslip.io, le service vous renvoie vers 13.42.26.29.

  • Pas de configuration, pas d’attente de propagation. C’est instantané.

La marche à suivre dans Dokploy :

Cliquez sur domain et « Add Domain »

Comme vous le voyez sur ma capture, la configuration est un jeu d’enfant :

  1. Host : On renseigne l’IP de notre VM suivie de .sslip.io (dans mon cas : 13.42.26.29.sslip.io).

  2. Container Port : Attention ici ! C’est le piège classique. Dokploy propose souvent le port 3000 par défaut. Mais notre image WordPress officielle, elle, écoute sur le port 80. Il faut donc impérativement changer cette valeur pour que Traefik sache où envoyer le trafic à l’intérieur du conteneur.

  3. HTTPS : Pour un test rapide sur sslip.io, on peut le laisser décoché. Si vous voulez du SSL, Traefik tentera de le générer, mais Let’s Encrypt peut parfois tiquer sur les domaines en sslip.io.

Une fois que c’est validé, on retourne dans l’onglet General, on clique sur Deploy, et on laisse la magie opérer.

Maintenant testons l’accès à l’interface de Wordpres:

 

Ca fonctionne!!

 

4) Le mot de la fin : Dokploy, on valide ou pas ?

Alors, après ce tour d’horizon, quel est le verdict pour un admin habitué à gérer ses propres serveurs ?

Soyons honnêtes : le « tout en ligne de commande », ça a son charme et c’est formateur. Mais à l’heure où l’on doit multiplier les environnements de test, les sites clients ou les outils de monitoring, on ne peut plus se permettre de passer 2 heures à configurer un reverse proxy ou à débugger un certificat SSL récalcitrant.

Dokploy réussit son pari : offrir une expérience PaaS moderne (le fameux « Heroku-like ») sans nous enfermer dans un cloud propriétaire. On garde nos données, on garde notre OS (Debian 12 dans mon cas), et surtout, on garde le contrôle sur ce qui tourne.

Ce qu’il faut retenir :

  • C’est rapide : L’installation « One-liner » et le déploiement via sslip.io permettent de voir son projet en ligne en quelques minutes.

  • C’est propre : On s’appuie sur des standards (Docker Swarm, Traefik, Nixpacks) que l’on peut auditer.

  • C’est souverain : Que votre VM soit chez vous, chez un hébergeur local ou sur un gros cloud public, c’est vous qui avez les clés du camion.

Mon conseil : Si vous avez une petite grappe de VPS qui traîne ou un serveur dédié qui ne demande qu’à être optimisé, testez Dokploy. C’est une excellente alternative à Coolify pour ceux qui cherchent une interface peut-être un peu plus légère et réactive.

Le cloud souverain ne se fera pas sans outils simples pour les admins. Dokploy est clairement un pas dans la bonne direction.