Récapitulation et examen final

Dix modules pour équiper un cabinet juridique avec un assistant local, du service d'inférence jusqu'à un système de questions-réponses branché sur les dossiers internes. Voici le cours condensé, puis les grandes lignes qui le traversent.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Installation	Service local sur 127.0.0.1:11434 ; OLLAMA_MODELS, OLLAMA_HOST, OLLAMA_KEEP_ALIVE sont les trois variables à connaître dès le premier jour
2. Gérer les modèles	Une étiquette nom:variante toujours explicite (jamais latest) ; pull, list, show, ps, rm couvrent le cycle de vie
3. Session et paramètres	temperature gouverne l'aléa, num_ctx a un coût mémoire réel, seed rend une génération reproductible, stop coupe une génération qui déborde
4. API locale	/api/ (natif) ou /v1/ (compatible OpenAI) ; stream=True améliore la latence perçue ; keep_alive par requête évite les recharges
5. Modelfile	FROM, SYSTEM, PARAMETER cristallisent une variante prête à l'emploi ; un Modelfile ne modifie pas les poids
6. Quantification	RAM ≈ taille du GGUF + cache d'attention ; q4_K_M est le plancher pratique, sous 4 bits la qualité chute sur les raisonnements longs
7. Accélération	CUDA / ROCm / Metal détectés automatiquement ; num_gpu pour le déchargement partiel ; eval rate est la mesure d'expérience utilisateur
8. Intégration	Script ollama-python avec format="json", LangChain via ChatOllama, Open WebUI en conteneur ; aucune authentification native, proxy inverse obligatoire au-delà de localhost
9. RAG local	Plongements avec nomic-embed-text, index Chroma persistant, consigne « uniquement à partir des passages, cite la source »
10. Limites	Écart aux modèles cloud sur raisonnement long, saturation au-delà de 20 utilisateurs, contexte plafonné vers 16 K, mises à jour trimestrielles à discipliner

Les fils qui traversent le cours

Tout est un client d'un même service HTTP. Que l'on tape ollama run, que l'on invoque ollama-python, que l'on branche ChatOllama ou Open WebUI, tout passe par le même port 11434. Cette phrase, prise au sérieux, dissout la moitié des confusions du débutant : un modèle chargé par la CLI est disponible pour Python, une consigne système figée dans un Modelfile s'applique à Open WebUI sans configuration supplémentaire, et l'authentification se traite une seule fois au niveau du proxy plutôt que dans chaque client.

La quantification, la RAM et la vitesse sont un même triangle. Choisir q4_K_M plutôt que q6_K libère de la mémoire pour agrandir num_ctx ou pour laisser le modèle sur GPU au lieu de le déchargeer partiellement en CPU. Chaque paramètre influence les deux autres ; il n'y a pas de « bon réglage » universel, seulement le triplet cohérent pour un matériel donné et un usage donné. Les mesures eval rate du module 7 sont l'arbitre final.

La consigne système est un artefact d'ingénierie, pas un texte marketing. L'expérience du module 5 puis du module 9 le confirme : figer la consigne du cabinet dans un Modelfile, la rendre strictement identique entre les scripts et l'interface, imposer « uniquement à partir des passages fournis » et « cite la source » sont ce qui distingue un assistant utilisable en production d'un chatbot amusant. Le prompt engineering n'est pas facultatif quand l'assistant sert de premier filtre sur des questions clients.

L'exécution locale est une infrastructure, pas un binaire. Un service qui tourne 24 heures sur 24 réclame les mêmes soins que n'importe quel autre serveur : mises à jour, journal, sauvegardes de l'index Chroma, banc d'essai régulier pour éviter les régressions silencieuses, proxy inverse authentifié et TLS. Le module 10 rappelle enfin que le local n'est pas toujours la meilleure réponse : entre le cloud, un serveur d'inférence dédié (vLLM, TGI) et Ollama, le bon choix dépend du couple charge attendue / qualité requise / sensibilité des données.

L'examen final

L'examen comporte 40 questions couvrant les dix modules : décodage d'une étiquette de modèle et de sa quantification, effet exact de num_ctx sur la mémoire et la vitesse, choix entre API native et API compatible OpenAI, construction d'un Modelfile avec ses paramètres, calcul honnête de la RAM nécessaire, arbitrage entre CPU et GPU avec déchargement partiel, exposition réseau et proxy inverse, construction d'un RAG local avec plongements et récupération, limites du service face à la concurrence, et arbitrage entre local, serveur dédié et cloud.

Plusieurs questions présentent des situations à diagnostiquer : un modèle qui ne se charge pas malgré pull réussi, une latence qui explose après un changement de contexte, une réponse qui invente une jurisprudence, un port exposé sans authentification, un banc d'essai qui dégrade brusquement après une mise à jour. C'est le jugement qui est évalué, pas la récitation de commandes.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Avant de commencer

Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous « quelle est la seule commande ou la seule variable que je dois retenir ? ». Si vous savez dire ce qui distingue q4_K_M de q8_0, pourquoi doubler num_ctx peut diviser la vitesse par dix, pourquoi Ollama sans proxy inverse est un incident de sécurité, et pourquoi un Modelfile n'apprend rien au modèle, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.