Créer son propre environnement d'intelligence artificielle ne signifie pas nécessairement louer un serveur, acheter une machine dédiée ou remplacer son système d'exploitation. Plusieurs solutions existent, chacune avec ses avantages, ses contraintes et ses possibilités d'évolution. Le choix initial dépend autant des besoins que des ressources disponibles et de la manière dont on souhaite utiliser son IA.
Chez Web-Soul, nous abordons cette question sous un angle particulier : construire une infrastructure modulaire, maîtrisable et évolutive, sans enfermer l'utilisateur dans une solution unique. L'objectif n'est pas de choisir une architecture pour toujours, mais de comprendre les options disponibles et de pouvoir passer de l'une à l'autre lorsque les besoins changent.
1. Trois architectures, trois approches
Une infrastructure IA peut être hébergée sur un serveur distant loué auprès d'un fournisseur, sur un ordinateur physique dédié à domicile ou directement sur l'ordinateur que l'on utilise quotidiennement. Ces trois approches peuvent partager une grande partie de leurs composants logiciels, mais elles ne répondent pas exactement aux mêmes besoins.
1.1. Le VPS : un serveur distant
Le VPS (Virtual Private Server) est un serveur virtuel loué auprès d'un hébergeur. Il dispose de ressources attribuées et fonctionne indépendamment de l'ordinateur personnel de son utilisateur. Il peut rester accessible en permanence et permettre l'administration des services à distance.
Cette solution évite l'achat et l'entretien d'un serveur physique. Elle implique toutefois un abonnement récurrent et des ressources limitées par l'offre choisie. Les performances des modèles d'IA dépendent notamment de la mémoire, du processeur et, lorsque cela est nécessaire, des capacités graphiques disponibles.
Le guide IA VPS Build de LABO Web-Soul présente cette approche. Il constitue notre parcours de référence pour apprendre à déployer une infrastructure composée de services isolés, administrés et reliés entre eux.
1.2. Le serveur local dédié : une machine chez soi
Un ordinateur physique peut remplir le même rôle qu'un VPS. Il suffit de lui consacrer une installation adaptée, par exemple Debian, puis d'y déployer les services nécessaires. Cette machine peut être un ancien ordinateur reconverti ou un équipement acheté spécifiquement pour cet usage.
L'utilisateur maîtrise alors son matériel, ses ressources et l'emplacement de ses données. Il n'a pas de location mensuelle de serveur à payer, mais il doit prendre en charge l'investissement initial, la consommation électrique, les sauvegardes, la maintenance et la disponibilité de la machine.
Un serveur local peut rester privé, accessible uniquement depuis le réseau domestique. Il peut également être rendu accessible à distance, à condition de mettre en place une configuration réseau et des protections appropriées. Ces deux usages ne doivent pas être confondus : exposer un service sur Internet modifie sensiblement les exigences de sécurité.
Le futur guide IA Local Server sera consacré à cette architecture.
1.3. L'ordinateur personnel : commencer avec ce que l'on possède
Une troisième possibilité consiste à exécuter les services IA sur son propre ordinateur, sans lui consacrer exclusivement une machine entière. L'utilisateur peut organiser les données sur un disque dédié tout en continuant à utiliser son environnement habituel.
Sous Windows, Docker Desktop permet notamment d'exécuter des conteneurs Linux dans un environnement virtualisé. Sous Linux, Docker Engine constitue une autre possibilité. Certains composants, comme Ollama, peuvent également être installés directement sur le système plutôt que dans un conteneur, selon l'architecture retenue.
Cette approche permet de commencer sans louer de serveur ni acheter immédiatement un nouvel ordinateur. En contrepartie, les services partagent les ressources de la machine avec les autres applications. Une mise en veille ou un arrêt de l'ordinateur interrompt les services qui en dépendent. Le futur guide IA Local Desktop présentera cette solution, avec des parcours adaptés à Windows et à Linux.
1.4. Comparatif des trois architectures
| Critère | IA VPS Build | IA Local Server | IA Local Desktop |
|---|---|---|---|
| Principe | Serveur virtuel loué à un hébergeur | Ordinateur physique dédié à domicile | Ordinateur personnel utilisé au quotidien |
| Matériel | Fourni par l'hébergeur | Choisi par l'utilisateur | Ordinateur existant ou mis à niveau |
| Coût récurrent | Abonnement mensuel | Électricité, connexion et maintenance | Consommation supplémentaire éventuelle |
| Investissement initial | Faible | Potentiellement important | Faible si le matériel existant suffit |
| Accès depuis Internet | Possible avec une configuration adaptée | À configurer si nécessaire | À configurer si nécessaire |
| Accès sur le réseau local | Possible selon la configuration réseau | Naturellement adapté | Naturellement adapté |
| Disponibilité permanente | Généralement prévue par l'hébergement | Si la machine reste allumée et opérationnelle | Dépend de l'utilisation de l'ordinateur |
| Ressources IA | Limitées par l'offre souscrite | Déterminées par le matériel choisi | Partagées avec les autres applications |
| Maintenance | Système et services à administrer | Matériel, système et services à administrer | Système et services à administrer |
| Usage privilégié | Services accessibles à distance | Infrastructure personnelle dédiée | Expérimentation et usage individuel |
Ce comparatif ne désigne pas une solution universellement supérieure. Il permet de comprendre les compromis à accepter. Un VPS simplifie la mise à disposition d'un serveur distant, tandis qu'une installation locale donne davantage de contrôle sur le matériel. L'ordinateur personnel permet, quant à lui, de commencer avec les ressources déjà disponibles.
2. Les composants peuvent rester les mêmes
Le choix de l'infrastructure ne détermine pas nécessairement les logiciels utilisés. Une grande partie de notre architecture repose sur des composants capables de fonctionner dans différents environnements, à condition de respecter leurs prérequis et de les configurer correctement.
- Debian ou Linux : le système d'exploitation du serveur, selon la solution retenue.
- Docker Engine et Docker Compose : le déploiement, l'isolation et l'organisation des services.
- Traefik : le routage des requêtes HTTP et HTTPS lorsque cette fonction est nécessaire.
- Ollama : l'exécution des modèles de langage compatibles.
- Qdrant : le stockage et la recherche de vecteurs pour les applications qui en ont besoin.
- AnythingLLM : l'interface de travail avec les modèles et les bases documentaires.
- n8n : l'automatisation des processus et la coordination de services.
La présence de tous ces composants n'est pas obligatoire dans chaque installation. Une configuration légère peut commencer avec un nombre réduit de services, puis s'enrichir lorsque les besoins le justifient.
2.1. Compatibilité des composants
| Composant | VPS | Serveur local dédié | Ordinateur personnel | Point d'attention |
|---|---|---|---|---|
| Debian | Oui | Oui | Possible, ou Linux déjà installé | Le parcours Windows ne nécessite pas d'installer Debian directement sur le PC. |
| Docker Engine | Oui | Oui | Oui sous Linux ; Docker Desktop sous Windows | Les modes d'installation et les exigences diffèrent. |
| Docker Compose | Oui | Oui | Oui | Les fichiers Compose sont largement portables, sous réserve des chemins et paramètres. |
| Traefik | Oui | Oui | Possible | Sa configuration dépend de l'accès réseau, des noms de domaine et du HTTPS. |
| Ollama | Oui, selon les ressources disponibles | Oui, selon le matériel | Oui, selon le matériel et le système | Les performances et les modèles utilisables dépendent des ressources. |
| Qdrant | Oui | Oui | Oui, selon les besoins | Prévoir le stockage persistant et les sauvegardes. |
| AnythingLLM | Oui | Oui | Oui, selon les prérequis | Configurer correctement la connexion au modèle et le stockage. |
| n8n | Oui | Oui | Oui, selon les besoins | Prévoir la persistance des données et sécuriser les accès. |
La portabilité n'est cependant pas absolue. Les chemins de stockage, les variables d'environnement, les réseaux Docker, les ports exposés, les méthodes d'accès et les ressources disponibles peuvent nécessiter des adaptations. Sous Windows, la gestion des conteneurs Linux et de leurs volumes présente également des particularités propres à Docker Desktop.
Il faut donc distinguer deux niveaux : les principes d'architecture, qui restent largement communs, et les procédures d'installation, qui doivent tenir compte de l'environnement cible.
3. Le choix du modèle IA dépend du matériel
Installer le même logiciel sur deux machines ne garantit pas les mêmes performances. Un modèle qui fonctionne correctement sur un serveur doté de ressources importantes peut se révéler trop lent ou trop exigeant en mémoire sur un ordinateur personnel.
Le choix du modèle doit donc tenir compte de plusieurs facteurs : la quantité de mémoire disponible, le processeur, la présence éventuelle d'un GPU compatible, la taille du modèle et les ressources consommées par les autres services.
Il faut également distinguer trois questions : le modèle peut-il être chargé, peut-il produire des réponses à une vitesse acceptable et dispose-t-il des capacités nécessaires pour accomplir la tâche demandée ? Ces critères ne sont pas équivalents.
Une architecture évolutive doit permettre de changer de modèle sans imposer systématiquement une refonte de l'infrastructure. Le modèle constitue un composant de la solution, pas toute la solution. Il est donc préférable de commencer par définir les tâches à accomplir, puis d'évaluer les modèles compatibles avec le matériel disponible. Cette démarche évite de choisir un modèle uniquement parce qu'il est populaire ou performant sur une autre machine.
4. Accès local, accès distant et sécurité
Un service IA exécuté sur un ordinateur n'a pas nécessairement besoin d'être accessible depuis Internet. Pour un usage personnel, l'accès depuis le navigateur de la machine ou depuis les autres ordinateurs du réseau local peut suffire. Le passage à un accès distant nécessite des choix supplémentaires. Il faut déterminer comment les noms de domaine sont résolus, comment les requêtes arrivent jusqu'aux services et comment les connexions sont sécurisées.
Traefik peut remplir le rôle de reverse proxy dans les trois architectures. En revanche, sa configuration ne sera pas forcément identique. Sur un VPS accessible publiquement, la validation des certificats HTTPS peut suivre une procédure différente de celle d'un serveur privé qui n'est pas joignable depuis Internet.
Le recours à des certificats privés, à une validation DNS ou à d'autres mécanismes dépend de l'architecture et des objectifs retenus. Il ne faut donc pas transposer aveuglément la configuration réseau d'un VPS à une machine locale. Enfin, un service qui n'a pas vocation à être public ne devrait pas être exposé inutilement. La limitation des ports accessibles, la gestion des identifiants, les mises à jour et les sauvegardes font partie de la conception de l'infrastructure, et non de simples opérations de finition.
5. Le coût réel d'une solution IA
Le prix mensuel d'un VPS est facile à identifier, mais il ne représente pas à lui seul le coût total d'une infrastructure. À l'inverse, un serveur local sans abonnement n'est pas gratuit pour autant.
Pour comparer les solutions, il faut tenir compte de plusieurs éléments : le coût du matériel, la durée d'utilisation prévue, la consommation électrique, les éventuels frais de stockage, la maintenance et le temps consacré à l'administration.
5.1. Comparatif des coûts et contraintes
| Élément | VPS | Serveur local dédié | Ordinateur personnel |
|---|---|---|---|
| Location mensuelle | Oui | Non | Non |
| Achat de matériel | Non, côté utilisateur | Oui, sauf matériel déjà disponible | Non, si le PC existant suffit |
| Électricité supplémentaire | Pas directement facturée à l'utilisateur par la consommation du serveur | Oui | Variable selon l'usage et la charge |
| Connexion Internet | Fournie par l'infrastructure de l'hébergeur | Connexion du domicile | Connexion habituelle |
| Disponibilité du service | Dépend de l'hébergeur et de la configuration | Dépend de l'alimentation, du réseau et du matériel | Dépend aussi de l'usage quotidien du PC |
| Maintenance matérielle | Principalement à la charge de l'hébergeur | À la charge de l'utilisateur | À la charge de l'utilisateur |
| Évolutivité des ressources | Par changement d'offre ou adaptation de l'infrastructure | Par remplacement ou ajout de matériel | Limitée par la configuration et les possibilités de mise à niveau |
| Contrôle physique des données | Non | Oui | Oui, sous réserve des services et stockages utilisés |
Il faut éviter d'affirmer qu'une solution locale sera toujours moins chère. Pour une comparaison économique sérieuse, il faudrait intégrer le prix du matériel, sa durée d'utilisation, sa consommation électrique et le coût du VPS sur la même période.
Un ordinateur déjà disponible peut constituer une base économique intéressante. En revanche, acheter une machine très performante uniquement pour exécuter des modèles IA peut représenter un investissement important. Le résultat dépend des besoins réels, de la durée d'utilisation et du niveau de performance recherché.
6. Une infrastructure peut évoluer
Le choix initial n'a pas besoin d'être définitif. Un utilisateur peut commencer sur son ordinateur personnel, passer ensuite à un serveur dédié ou louer un VPS lorsque ses besoins changent. Il peut également suivre le chemin inverse si le coût d'un serveur distant ne se justifie plus.
Prenons un exemple : une personne déploie son environnement sur un VPS, puis souhaite réduire ses dépenses après un an. Elle peut envisager de transférer ses services vers un ordinateur installé chez elle, sous réserve que le matériel local soit suffisant et que les données puissent être migrées correctement.
Cette opération ne consiste pas simplement à copier un répertoire. Il faut inventorier les services et leurs versions, sauvegarder les données persistantes, conserver les paramètres nécessaires, préparer la nouvelle infrastructure, restaurer les données et vérifier le fonctionnement de chaque composant.
Les accès réseau et les noms de domaine devront également être adaptés. Une adresse publique ou un nom utilisé sur le VPS ne se transpose pas automatiquement à un réseau privé.
6.1. Les principales migrations possibles
| Migration | Objectif | Éléments à conserver | Adaptations principales |
|---|---|---|---|
| VPS vers serveur local | Réduire les frais d'hébergement ou reprendre le contrôle du matériel | Données sauvegardées, configurations, fichiers Compose et versions compatibles | Réseaux, adresses, noms de domaine, certificats et ressources matérielles |
| Ordinateur personnel vers serveur local | Disposer d'une machine dédiée et plus disponible | Données persistantes, paramètres et modèles selon le mode de stockage | Chemins, volumes, permissions et configuration réseau |
| Serveur local vers VPS | Faciliter l'accès distant ou disposer d'une infrastructure hébergée | Données sauvegardées, configurations et versions compatibles | Ressources disponibles, réseau public, sécurité et exposition des services |
| Ordinateur personnel vers VPS | Rendre les services indépendants du PC quotidien | Données, configurations et paramètres nécessaires à la restauration | Déploiement distant, stockage, accès réseau et ressources du VPS |
| VPS vers ordinateur personnel | Expérimenter localement ou supprimer l'abonnement | Données et configurations compatibles avec la nouvelle installation | Capacité matérielle, chemins, disponibilité et accès réseau |
| Serveur local vers ordinateur personnel | Revenir à une installation plus légère | Données et configurations nécessaires | Ressources partagées, démarrage des services et disponibilité |
La migration n'est jamais garantie par la seule présence de Docker Compose. Chaque service peut nécessiter une procédure spécifique de sauvegarde et de restauration. Il faudra aussi vérifier la compatibilité des versions et les éventuelles différences entre systèmes.
Pour limiter les difficultés, il est préférable de conserver une documentation précise des versions, des paramètres et des volumes utilisés. Une sauvegarde doit également être testée : un fichier de sauvegarde dont la restauration échoue n'apporte aucune garantie réelle.
Lors d'une migration, il est prudent de conserver l'ancienne installation jusqu'à ce que la nouvelle ait été testée. Cette précaution permet de revenir en arrière en cas de problème.
7. Un socle commun, plusieurs parcours
LABO Web-Soul a vocation à proposer des parcours distincts plutôt qu'un tutoriel unique censé convenir à toutes les situations.
- IA VPS Build : construire une infrastructure sur un serveur distant.
- IA Local Server : héberger les services sur une machine physique dédiée.
- IA Local Desktop : commencer sur son ordinateur personnel, sous Windows ou Linux.
Chaque guide devra fournir des instructions adaptées à son environnement. Les principes communs pourront être expliqués une seule fois lorsque cela est pertinent, avec des liens vers les notions correspondantes. Les différences qui modifient réellement les opérations à effectuer devront, elles, être présentées clairement dans chaque parcours.
Cette organisation permettra également de documenter les évolutions des logiciels et des méthodes de déploiement sans perdre la cohérence de l'ensemble. Les versions, les configurations et les procédures devront être révisées au fil des évolutions techniques.
Une convention commune concernant les noms des services, les réseaux Docker, les volumes persistants, les variables d'environnement et les sauvegardes facilitera le maintien de cette cohérence. Elle permettra également de mieux préparer les migrations d'une architecture à l'autre.
8. Par où commencer ?
Le choix dépend principalement de l'objectif recherché.
| Votre situation | Parcours conseillé | Pourquoi ? |
|---|---|---|
| Vous souhaitez disposer de services accessibles à distance sans gérer le matériel physique. | IA VPS Build | L'hébergement fournit une infrastructure distante dont vous administrez le système et les services. |
| Vous possédez ou souhaitez acquérir une machine dédiée à votre infrastructure IA. | IA Local Server | Vous maîtrisez le matériel et l'environnement d'hébergement. |
| Vous souhaitez expérimenter sans acheter de serveur. | IA Local Desktop | Vous pouvez commencer avec votre ordinateur existant, si ses ressources sont suffisantes. |
| Vous utilisez déjà un VPS et souhaitez réduire les dépenses d'hébergement. | Migration VPS vers serveur local | Vous pouvez préparer le transfert des services et des données sans reconstruire toute l'architecture. |
| Votre installation locale devient insuffisante. | Migration vers un serveur dédié ou un VPS | Vous pouvez adapter les ressources à vos nouveaux besoins. |
Dans tous les cas, il est préférable de commencer par une installation minimale, de vérifier son fonctionnement et d'ajouter les composants au fur et à mesure des besoins. Cette méthode facilite le diagnostic, limite la complexité initiale et permet de mieux comprendre le rôle de chaque service.
L'objectif de LABO Web-Soul n'est pas d'imposer une infrastructure unique, mais de donner les moyens de comprendre, de construire et de faire évoluer son propre environnement IA. Le choix du matériel et de l'hébergement peut changer. Les principes d'organisation, de sécurité, de sauvegarde et de maîtrise des composants doivent, eux, rester au centre de la démarche.
