Réponse courte. Déployer un modèle sur ses serveurs n'est pas une marque de sérieux : c'est la réponse à une contrainte écrite, où les documents ont le droit d'aller. Quand elle existe, banque, administration, santé, site industriel isolé, on installe un modèle ouvert sur une machine à vous, derrière la même orchestration que pour une API : instructions, récupération de documents, schémas, repli humain, journal. Le modèle se choisit sur votre jeu d'évaluation de soixante cas réels, en arabe, en français et en darija, pas sur un classement : la taille ne dit pas la langue. La machine se dimensionne sur la mémoire des poids, environ 2 Go par milliard de paramètres en 16 bits et 0,6 Go en 4 bits, plus le contexte. Un serveur d'inférence regroupe les requêtes, met le préfixe en cache et sert des poids quantifiés ; c'est ce qui fait qu'une carte sert une équipe. Le coût devient fixe, une machine et son exploitation, au lieu d'être à la requête. Et quand la contrainte n'existe pas, une API en Europe arrive plus vite et répond mieux. Dix semaines, et aucune carte achetée avant la quatrième.
Ce guide s'adresse à la direction informatique d'une banque, d'une assurance ou d'une administration à qui l'on a dit que l'IA « c'est dans le cloud », à la clinique et à l'industriel dont les données ne sortent pas, et à l'éditeur de SaaS dont un client exige que tout reste en Algérie. Il ne redit pas quelles fonctions construire, décrit dans le guide sur l'IA dans l'application, ni où héberger l'application elle-même, décrit dans le guide sur l'hébergement ; il décrit ce qui se monte entre l'orchestration et la carte graphique, et il prolonge notre page sur les fonctions IA.
Ce que les chiffres disent
La taille d'un modèle ne dit pas sa langue. La fiche du modèle Llama 3.3 de 70 milliards de paramètres, publiée par Meta le 6 décembre 2024 avec une fenêtre de contexte de 128 000 tokens, liste huit langues officiellement prises en charge : anglais, allemand, français, italien, portugais, hindi, espagnol et thaï ; l'arabe n'y figure pas, et la fiche précise que les développeurs peuvent l'affiner pour d'autres langues. À l'inverse, la famille Jais 3, annoncée le 15 octobre 2026 par l'institut des modèles de fondation de MBZUAI et Inception42, propose six modèles ouverts de 900 millions à 375 milliards de paramètres construits pour l'arabe standard et des dialectes « jusqu'à l'arabe d'Afrique du Nord » ; nous citons l'annonce de presse, et la licence se lit sur le dépôt. Ce que cela impose : le modèle se choisit sur vos documents et vos messages, en arabe, en français et en darija, pas sur le nombre de paramètres.
Une machine sert plusieurs personnes à condition d'avoir le bon serveur. La documentation de vLLM, bibliothèque ouverte d'inférence que nous utilisons, liste le regroupement continu des requêtes entrantes, la mise en cache du préfixe, la gestion de la mémoire d'attention, des poids quantifiés en 8 et 4 bits dans plusieurs formats, une API compatible avec celle des éditeurs, la prise en charge des cartes NVIDIA et AMD, et le parallélisme sur plusieurs cartes. Ce que cela impose : passer d'une API à un modèle sur site ne réécrit pas l'application, puisque l'orchestration parle la même API ; et la question n'est pas « combien de tokens par seconde » mais « combien de personnes en même temps, avec quelle attente ».
La mémoire se calcule avant d'acheter. Un poids stocké en 16 bits occupe deux octets : un modèle occupe donc environ 2 Go par milliard de paramètres, et environ 0,6 Go en 4 bits ; s'y ajoute la mémoire du contexte, qui grandit avec la longueur des documents et le nombre de requêtes simultanées. Ce sont des ordres de grandeur, pas une fiche technique : un modèle de 8 milliards tient en 4 bits sur une carte de 24 Go avec de la marge, un modèle de 32 milliards y tient juste, un modèle de 70 milliards demande 48 Go ou plusieurs cartes. Ce que nous n'avons pas trouvé et ne citons pas : un prix public des cartes en Algérie, qui dépend de l'importation et change ; c'est pourquoi le modèle se choisit d'abord sur des machines louées à l'heure, et la machine s'achète ensuite.
Une requête, deux chemins
Le déploiement privé ne remplace pas l'API : il ajoute un chemin, et l'orchestration choisit, requête par requête.
Dans vos murs : l'application appelle l'orchestration, qui prépare la requête, récupère les seuls documents utiles et appelle le modèle servi sur votre machine ; rien ne sort du réseau, ni le document, ni la question, ni la réponse, ni le journal. C'est le chemin de tout ce qui contient un document de client, un dossier médical, une pièce d'identité. Hors de vos murs : pour ce qui n'en contient pas, une rédaction générale, une traduction, une question sur un texte public, l'orchestration peut appeler un modèle plus capable hébergé en Europe, avec les seules données nécessaires et un contrat à votre nom. La règle est écrite la première semaine, par type de requête, et elle est appliquée par l'orchestration, pas laissée au jugement de l'utilisateur.
Ce que cela change : les documents ne vont nulle part ; le coût devient fixe, une machine et son exploitation, au lieu de croître avec chaque requête et de se payer en devise comme le guide sur le paiement du cloud le décrit ; et la qualité devient une question à mesurer, parce qu'un modèle ouvert de taille moyenne ne vaut pas le meilleur modèle fermé sur toutes les tâches, mais tient très bien une extraction, un tri ou une recherche dans vos documents. Un seul des deux chemins n'est presque jamais la bonne réponse : tout sur site prive des modèles les plus capables ce qui n'a rien de sensible, tout en Europe exclut ce qui ne doit pas sortir.
Un modèle sur vos serveurs, en cinq couches
Cinq couches, dont deux sont exactement celles d'une fonction construite sur une API.
L'application ne change pas : elle appelle l'orchestration et ne sait pas où tourne le modèle. L'orchestration est la même que celle décrite dans le guide sur l'IA dans l'application : instructions versionnées, récupération, schémas de sortie, seuils, repli humain, journal ; elle gagne une règle, le choix du chemin. Le serveur de modèles est la couche qu'on ajoute : un serveur d'inférence ouvert qui expose une API compatible, regroupe les requêtes qui arrivent ensemble, garde le préfixe commun en cache et sert des poids quantifiés ; changer de modèle est un fichier et un redémarrage, pas un projet.
La machine porte une ou plusieurs cartes graphiques, de la mémoire, du stockage pour les poids et les index, un onduleur, un réseau interne et aucun accès sortant ; elle se dimensionne sur la taille du modèle retenu et le nombre de requêtes simultanées mesuré au pilote. L'exploitation lit chaque semaine la charge de la carte, la file d'attente, la latence et la note sur le jeu d'évaluation, sauvegarde les poids et les index, et fait passer toute mise à jour de modèle par le jeu d'évaluation avant la production, comme le guide sur la livraison le fait pour le code.
«Le déploiement sur site n'est pas une marque de sérieux : c'est la réponse à une contrainte écrite, où les documents ont le droit d'aller.»
Quel modèle tient sur quelle carte
La question « quelle machine faut-il » se répond dans l'autre sens : quel modèle tient la note sur vos cas, et quelle mémoire lui faut-il.
Les petits modèles, autour de 8 milliards de paramètres, tiennent en 4 bits dans environ 5 Go : ils suffisent pour trier des messages en catégories fermées et extraire des champs simples, et répondent vite à beaucoup de monde. Autour de 14 milliards, environ 9 Go en 4 bits : extraction de documents plus variés, résumés. Autour de 32 milliards, environ 20 Go en 4 bits, donc sur une carte de 24 Go avec peu de marge pour le contexte, ou à l'aise sur 48 Go : recherche dans les documents avec réponse sourcée, agents avec outils. Autour de 70 milliards, environ 42 Go en 4 bits : raisonnement plus long et rédaction, sur une carte de 48 Go ou plusieurs cartes.
La quantification en 4 bits divise la mémoire par plus de trois et coûte un peu de qualité ; combien, cela se mesure sur votre jeu d'évaluation, fonction par fonction, et ne se suppose pas. La langue passe avant la taille : un modèle de 70 milliards qui ne liste pas l'arabe peut faire moins bien sur un vocal en darija qu'un modèle arabe quatre fois plus petit, et la transcription des vocaux se fait avec un modèle de reconnaissance dédié. La règle : le plus petit modèle qui tient la note sur chaque fonction, souvent deux modèles sur la même machine, un petit pour le tri et un moyen pour la recherche, plutôt qu'un gros pour tout.
Six situations, et ce qu'on monte pour chacune
Six situations que nous rencontrons, et le montage retenu la première semaine pour chacune.
La banque, l'assurance, l'administration : les documents des clients ne sortent pas de l'établissement, parfois pas du réseau ; tout sur site, modèle ouvert, index et journal sur vos serveurs, aucun accès sortant, et une deuxième machine pour la reprise. La clinique, le laboratoire : lecture de dossiers et d'ordonnances sur site ; rédaction générale vers l'Europe sans données de patient ; montage mixte. L'industriel, le site isolé : la connexion ne tient pas ; petit modèle sur une carte, hors ligne, mises à jour apportées, journal synchronisé quand la liaison revient, sur le principe du mode hors ligne.
Le distributeur, le portail B2B : catalogue et commandes peu sensibles ; API en Europe d'abord, avec cache et récupération ; le passage sur site se décide quand le volume mensuel rend la machine moins chère que les requêtes. Le fondateur en France : pas de salle serveur, un lancement à tenir ; API en Europe, orchestration à lui dès le départ, et le passage sur site reste possible sans réécrire. L'éditeur de SaaS : des clients qui acceptent l'Europe, d'autres qui exigent l'Algérie ou leurs murs ; les deux chemins dans la même orchestration, choisis par client, comme l'isolation décrite dans le guide sur le SaaS multi-tenant, et un modèle sur site vendu comme une offre.
«La taille ne dit pas la langue : le modèle se choisit sur vos cas en arabe, en français et en darija, puis la machine se déduit du modèle.»
Six échecs d'un modèle sur site
Six échecs que nous voyons sur les déploiements privés que nous reprenons, et ce que l'architecture fait contre chacun.
La carte saturée : vingt personnes posent une question en même temps et chacune attend une minute ; requêtes regroupées par le serveur, file avec priorité, limite de tokens, petit modèle pour le tri, charge lue chaque semaine. Le modèle trop grand : on a pris le plus gros « pour être sûr », et il ne tient pas ou répond en dix secondes ; taille choisie par fonction sur le jeu d'évaluation, quantification mesurée, le plus petit qui tient la note. L'arabe mal servi : le modèle choisi sur un classement en anglais répond mal en arabe et en darija ; modèles comparés sur vos soixante cas réels dans les trois langues, modèle arabe pour la voix et le dialecte.
La mise à jour qui casse : un nouveau modèle remplace l'ancien et trois fonctions régressent sans que personne le voie ; tout changement de modèle ou de quantification passe par le jeu d'évaluation, livraison refusée si la note baisse, retour arrière en une commande. Le serveur exposé : l'API du modèle répond sur le réseau sans authentification ; serveur joignable par l'orchestration seule, aucun accès sortant, journal par utilisateur, clés tournées. La machine unique : la carte tombe, ou le courant ; onduleur, sauvegarde des poids et des index, deuxième machine, ou repli écrit vers l'Europe pour ce qui a le droit d'y aller. Aucune ne se règle en achetant une carte plus grosse.
Vu ailleurs : la fiche de Llama, Jais 3, vLLM, et ce qui se transpose
Trois sources disent l'essentiel. La fiche de Llama 3.3 dit qu'un modèle de 70 milliards de paramètres liste huit langues dont l'arabe ne fait pas partie ; ce qui se transpose, c'est qu'un grand modèle généraliste doit être testé sur votre arabe avant d'être installé. L'annonce de Jais 3 dit que des modèles ouverts construits pour l'arabe et ses dialectes existent en plusieurs tailles ; ce qui se transpose, c'est qu'un modèle arabe de taille moyenne est un candidat sérieux pour la voix et le dialecte, à comparer sur vos cas.
La documentation de vLLM dit qu'un serveur ouvert regroupe les requêtes, met le préfixe en cache, sert des poids quantifiés et expose une API compatible ; ce qui se transpose, c'est qu'une fonction construite sur une API passe sur site sans réécriture si l'orchestration est à vous. Ce que ces sources ne disent pas : quels documents ont le droit de sortir chez vous, combien de personnes interrogeront le modèle en même temps, et quel modèle tient la note sur vos cas ; les quatre premières semaines du projet y répondent, sans achat.
Les règles d'un modèle sur site qui tient
Six règles, écrites la première semaine. La contrainte d'abord : où chaque type de document a le droit d'aller, par écrit, avant tout choix technique. Le jeu d'évaluation choisit le modèle, en arabe, en français et en darija ; pas un classement. Rien ne s'achète avant la comparaison sur des machines louées à l'heure. Le plus petit modèle qui tient la note, par fonction ; deux modèles plutôt qu'un gros. L'orchestration est la même que pour une API, et elle est à vous : le chemin est un réglage. Toute mise à jour passe par le jeu d'évaluation, avec retour arrière.
Une septième règle porte sur le devis : « IA souveraine sur site » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « liste des types de documents et de leur chemin autorisé ; modèle ouvert choisi sur soixante cas réels dans les trois langues, note mesurée ; machine dimensionnée pour N requêtes simultanées avec temps d'attente mesuré au test de charge ; serveur d'inférence avec regroupement et cache ; aucun accès sortant ; journal par requête ; sauvegarde des poids et des index ; procédure de mise à jour et de retour arrière ; reprise écrite », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « un serveur GPU » a chiffré une machine, pas une fonction.
Six fonctions, et sur quel chemin on les met
Six fonctions que nous construisons souvent, et le chemin retenu quand une contrainte existe.
- Lecture de factures, de pièces et de dossiers. Sur site : c'est le document lui-même qui est sensible ; modèle de lecture puis modèle moyen pour la mise en champs.
- Recherche dans les contrats et les procédures. Sur site : index et documents sur vos serveurs, réponse sourcée ; la partie mots-clés suit le guide sur la recherche.
- Tri des messages et des courriers. Sur site, petit modèle : catégories fermées, beaucoup de volume, réponse rapide.
- Transcription de vocaux en darija. Sur site quand les vocaux viennent de clients : modèle de reconnaissance arabe multidialectal, testé sur vos vocaux.
- Agent sur WhatsApp. Le message transite par Meta quel que soit le modèle, comme le guide sur l'agent WhatsApp le décrit ; le modèle peut être sur site, mais le canal ne l'est pas, et cela se dit au client.
- Rédaction générale, traduction, résumé de textes publics. Europe : aucune donnée sensible, et les modèles les plus capables y sont.
Le calendrier 2027
Le calendrier est celui d'un déploiement privé complet en dix semaines, dont deux sans code et aucune carte achetée avant la quatrième.
La semaine 0 à 1 écrit la contrainte et les fonctions : où chaque type de document a le droit d'aller, les deux ou trois fonctions, ce qui reste sur site et ce qui peut sortir ; signé. La semaine 1 à 2 écrit le jeu d'évaluation : soixante cas réels en arabe, en français et en darija, avec la bonne réponse. Les semaines 2 à 4 choisissent le modèle : trois ou quatre modèles ouverts comparés sur le jeu, sur des machines louées à l'heure, en 16 et en 4 bits ; la taille et la quantification retenues décident de la machine. Les semaines 4 à 6 installent la machine et le serveur de modèles, sans accès sortant, avec cache, file et test de charge au nombre réel d'utilisateurs.
Les semaines 6 à 9 branchent l'orchestration sur le modèle sur site et livrent les fonctions une à une, puis le pilote avec repli humain, la part passée à l'humain et l'attente lues chaque jour. La semaine 9 à 10 installe l'exploitation : supervision hebdomadaire, sauvegarde des poids et des index, procédure de mise à jour par le jeu d'évaluation, et une répétition de la panne de la machine. Le coût de fonctionnement, électricité, maintenance, remplacement, rejoint le budget annuel décrit dans le guide sur faire vivre une application.
Ce qui fait échouer un déploiement privé
Les déploiements privés que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- La machine achetée d'abord. Une carte choisie sur une fiche technique, puis un modèle qu'on cherche à y faire tenir.
- Le modèle choisi sur un classement. Premier en anglais, médiocre sur vos documents en arabe.
- Pas de serveur d'inférence. Un script qui charge le modèle et sert une personne à la fois.
- Tout sur site par principe. Des tâches sans aucune donnée sensible privées des meilleurs modèles.
- Pas de jeu d'évaluation. La qualité est une impression, et chaque mise à jour un pari.
- L'API du modèle ouverte sur le réseau. Sans authentification, sans journal ; personne ne sait qui a demandé quoi.
- Pas de reprise. Une seule machine, pas de sauvegarde des index ; la panne dure des semaines.
Questions fréquentes
Les questions que nous recevons de directions informatiques, de gérants en Algérie et d'éditeurs de SaaS.
- Faut-il déployer le modèle sur nos serveurs ?
- Seulement si une contrainte écrite l'exige : des documents de clients, des dossiers de santé ou des données qui ne doivent pas sortir de l'établissement ou du pays, ou un site sans connexion fiable. Sans cette contrainte, une API hébergée en Europe, derrière une orchestration qui vous appartient, arrive plus vite et donne accès aux modèles les plus capables ; et le passage sur site reste possible plus tard sans réécrire.
- Quel modèle ouvert choisir pour l’arabe et le français ?
- Celui qui tient la note sur vos soixante cas réels, dans les trois langues, darija comprise. La taille ne dit pas la langue : la fiche d'un grand modèle généraliste de 70 milliards de paramètres liste huit langues sans l'arabe, alors que des familles construites pour l'arabe et ses dialectes existent en plusieurs tailles. Nous comparons trois ou quatre candidats sur des machines louées avant tout achat.
- Quelle machine faut-il ?
- Elle se déduit du modèle retenu : environ 2 Go de mémoire par milliard de paramètres en 16 bits et 0,6 Go en 4 bits, plus le contexte et les requêtes simultanées. Un modèle de 8 à 14 milliards tient à l'aise sur une carte de 24 Go en 4 bits ; 32 milliards y tient juste ou confortablement sur 48 Go ; 70 milliards demande 48 Go ou plusieurs cartes. Ce sont des ordres de grandeur ; le test de charge avec votre nombre réel d'utilisateurs tranche.
- Combien de personnes une machine peut-elle servir ?
- Cela dépend du serveur plus que de la carte : un serveur d'inférence qui regroupe les requêtes arrivant ensemble et garde le préfixe en cache sert une équipe là où un script sert une personne. Le nombre exact se mesure au test de charge de la cinquième semaine, avec vos documents et votre longueur de réponse, et la file d'attente est lue chaque semaine ensuite.
- Est-ce plus coûteux qu’une API ?
- Le coût change de nature : fixe, une machine, son électricité et son exploitation, au lieu d'être à la requête et en devise. En dessous d'un certain volume, l'API coûte moins ; au-delà, la machine se rembourse. Le seuil se calcule avec votre volume mesuré au pilote, pas avec un chiffre général, et la contrainte sur les documents décide souvent avant le coût.
- Combien de temps pour déployer ?
- Dix semaines : une pour la contrainte et les fonctions, une pour le jeu d'évaluation, deux pour choisir le modèle sur des machines louées, deux pour la machine et le serveur de modèles, trois pour les fonctions et le pilote, une pour l'exploitation et la reprise. Aucun achat de matériel avant la quatrième semaine.