Une organisation souhaite exploiter ses documents avec une IA tout en maîtrisant leurs conditions de traitement. Elle peut utiliser une API, déployer un modèle sur ses propres serveurs ou confier une plateforme dédiée à un hébergeur. Ces options répartissent différemment les coûts, les accès et le travail d’exploitation.
Le choix commence par l’usage et les contraintes. Une application qui extrait des données, un assistant documentaire et un agent connecté à un ERP n’ont pas les mêmes exigences. Un essai représentatif permet de définir le résultat attendu avant de choisir le modèle et l’environnement qui le produiront.
Définir le service et son niveau de qualité
Pour un assistant documentaire, l’équipe prépare des questions dont elle connaît les sources et les réponses attendues. Elle ajoute des documents contradictoires, des versions remplacées et des demandes qui dépassent les droits d’un utilisateur. L’évaluation examine la réponse avec ses citations, puis le comportement face à l’incertitude.
Pour une extraction, l’essai vérifie les champs, les formats et le traitement des valeurs absentes. Pour un agent, il examine aussi les actions et les reprises après erreur. Un test de rédaction ne valide donc pas les champs attendus par un extracteur ni les appels API exécutés par un agent.
Les performances font partie du service attendu. L’organisation précise le délai acceptable, la longueur des documents et le nombre de demandes simultanées. Une démonstration avec un utilisateur et trois pages ne représente pas une application partagée qui reçoit des dossiers volumineux.
Le jeu d’évaluation conserve les versions des données et les règles de notation. L’équipe peut comparer un nouveau modèle au précédent, puis vérifier qu’un changement de paramètre ou d’infrastructure ne dégrade pas les résultats retenus.
Comparer trois modes de déploiement
Les modèles à poids ouverts rendent possible une exploitation dans un environnement choisi, sous réserve de leur licence et des ressources nécessaires. Leur ouverture ne signifie pas que tous les modèles tiennent sur une machine de bureau. La mémoire requise comprend les poids, le contexte et les besoins du logiciel d’exécution.
| Mode | Travail pris en charge par l’organisation | Points déterminants |
|---|---|---|
| API d’un fournisseur | Intégration, données envoyées, droits et suivi des appels | Contrat, conservation, catalogue, disponibilité et coût d’usage |
| Serveur sur site | Installation, capacité, sécurité, maintenance et reprise | Ressources disponibles, charge réelle et compétences d’exploitation |
| Plateforme dédiée hébergée | Répartition contractuelle de l’administration et de l’exploitation | Accès techniques, isolation, engagements de service et réversibilité |
Un serveur local peut répondre à une contrainte d’isolement ou de maîtrise des échanges. Il demande toutefois une gestion des mises à jour, des comptes, de la supervision et des sauvegardes. Une panne matérielle ou l’absence d’un administrateur doit avoir une réponse prévue.
Une API simplifie certaines tâches d’exploitation et peut donner accès à un modèle plus volumineux. L’organisation dépend de son opérateur, de ses versions et de ses conditions de service. Un environnement dédié permet une autre répartition, à préciser plutôt qu’à déduire de son nom commercial.
Les services d’IA d’Infomaniak illustrent une offre hébergée en Suisse. La fiche technique d’Apertus illustre un modèle dont l’organisation peut examiner les éléments publiés. Une offre d’hébergement et une fiche de modèle apportent des informations complémentaires ; aucune ne remplace le test de l’application complète.
Examiner le trajet des données et les accès
La résidence suisse des données est un critère, mais le contrôle dépend également de l’opérateur et du contrat. L’organisation examine les sous-traitants, les accès d’assistance, les clés, la conservation et les possibilités d’utilisation des données. Le rapport fédéral sur le CLOUD Act explique pourquoi le lieu de stockage ne suffit pas à déterminer les risques d’accès étranger.
Un engagement de non-entraînement répond à une question particulière. Il ne décrit pas nécessairement la conservation des requêtes pour l’exploitation, l’accès du personnel ou les transferts entre composants. L’équipe lit les conditions du produit effectivement utilisé et vérifie les paramètres disponibles.
En local, le trajet comprend aussi la télémétrie, les mises à jour, les outils externes et les sauvegardes. Un modèle téléchargé peut être appelé par une application qui transmet des informations à un autre service. Le test doit donc observer l’ensemble des échanges nécessaires à l’usage.
Pour un agent connecté aux systèmes métier, les autorisations sont une décision d’architecture distincte. Le modèle ne reçoit que les outils et données nécessaires à sa tâche. Le code qui exécute ses demandes contrôle les actions, avec les validations humaines retenues selon leurs conséquences.
Assembler les composants et préparer leur remplacement
Un service d’IA interne associe l’authentification, les jobs de préparation documentaire, un index de recherche éventuel, le serveur d’inférence et la collecte des logs. La fiche de chaque service enregistre la version déployée et les paramètres appliqués. Elle identifie aussi les comptes autorisés à administrer le service.
vLLM fournit des fonctions d’inférence et de service de modèles. Ollama propose une autre manière de les exécuter et de les exposer. Le choix dépend des modèles, du matériel, des interfaces et de la charge. L’interface destinée aux utilisateurs et l’intégration à l’annuaire restent des éléments à concevoir.
Une recherche documentaire peut utiliser un index lexical, vectoriel ou hybride. Son rôle consiste à retrouver les passages autorisés pour la question courante. Ce mécanisme ne doit pas être confondu avec la mémoire persistante d’un agent, qui conserve des informations entre sessions.
La modularité facilite un remplacement si les interfaces et les données restent maîtrisées. L’équipe teste un changement de modèle sur le même jeu d’évaluation, vérifie les formats et prépare une solution de repli. Une compatibilité annoncée avec une API ne garantit pas des réponses identiques.
Décider sur le résultat d’un pilote
Le pilote réunit les critères de qualité, les mesures de performance et le coût complet. Pour une API, l’équipe compte les appels, les volumes et les reprises. Pour un service local, elle ajoute le matériel, l’énergie, l’administration et les moyens de continuité. Les deux options doivent rendre un service comparable.
La décision peut privilégier la maîtrise des données, une fonction du modèle ou une capacité d’exploitation déjà disponible. L’intérêt du pilote est de rendre cet arbitrage explicable. L’organisation sait ce qu’elle accepte, ce qu’elle doit encore améliorer et quels changements imposeront une nouvelle évaluation.
Les offres et les modèles évolueront. Un usage défini, un jeu d’essai versionné et une architecture dont les dépendances sont connues permettent de réexaminer le choix sans recommencer toute l’analyse.
Pour poursuivre, consulter les articles sur les critères pour sélectionner un modèle à poids ouverts et dimensionner une installation locale.