La question revient régulièrement chez nos clients les plus soucieux de confidentialité des données : peut-on se passer complètement d’un fournisseur d’API externe et héberger son propre modèle de langage sur un serveur qu’on contrôle ? En 2023, plusieurs modèles ouverts de taille raisonnable étaient enfin disponibles. Nous avons testé la faisabilité réelle sur des tâches WordPress typiques : classification de commentaires, génération de résumés, reformulation de texte.
Ce comparatif ne traite pas les assistants de code, qui relèvent d’un usage différent. Il porte sur l’intégration d’un modèle auto-hébergé dans des flux éditoriaux WordPress classiques, comparée à un appel à une API commerciale.
Le protocole de test
Nous avons servi un modèle ouvert de taille moyenne sur un serveur dédié, via une interface HTTP locale compatible avec le format de requête habituel des API de complétion, et comparé ses résultats à ceux d’une API commerciale sur trois tâches : modération de commentaires, résumé d’articles de 1 500 mots, et reformulation de méta-descriptions. Chaque tâche a été testée sur cinquante contenus réels issus de sites clients, résultats anonymisés.
La qualité : correcte sur les tâches simples, en retrait sur le reste
Sur la modération de commentaires, une tâche de classification relativement simple, l’écart de qualité entre le modèle ouvert et l’API commerciale restait faible, les deux détectant correctement la grande majorité des cas évidents de spam ou de contenu abusif.
Sur le résumé d’articles longs et la reformulation nuancée de méta-descriptions, l’écart se creusait nettement : le modèle ouvert produisait plus souvent des résumés qui reprenaient des phrases entières de l’article plutôt que de réellement synthétiser, et des reformulations parfois maladroites en français, langue moins représentée dans son corpus d’entraînement que l’anglais.
La latence, obstacle numéro un sans GPU dédié
Sur un serveur sans carte graphique dédiée, en inférence CPU pure, la latence moyenne observée pour générer une réponse de longueur moyenne dépassait largement celle d’une API commerciale, avec des pointes bien plus hautes encore sur les contenus les plus longs. Ce délai reste incompatible avec un usage dans l’éditeur, où le rédacteur attend une réponse en quelques secondes.
| Configuration | Latence moyenne observée | Usage viable |
|---|---|---|
| API commerciale | 2 secondes | Éditeur, temps réel |
| Modèle ouvert, CPU seul | 8 secondes | Tâche de fond uniquement |
| Modèle ouvert, GPU dédié | 3 secondes | Éditeur, avec limites |
Avec un GPU dédié loué à l’heure, la latence redevient acceptable pour un usage interactif, mais au prix d’une infrastructure bien plus coûteuse et complexe à maintenir qu’un simple appel HTTP vers une API tierce.
Le coût réel, sur de petits volumes, ne favorise pas l’auto-hébergement
C’est le résultat le plus contre-intuitif du test. Sur des volumes modestes, quelques centaines d’appels par mois, le coût d’un serveur GPU dédié loué en continu dépasse largement le coût des appels équivalents facturés à l’usage sur une API commerciale, qui ne facture que ce qui est réellement consommé. L’auto-hébergement ne devient économiquement avantageux qu’à partir d’un volume d’appels important et régulier, suffisant pour rentabiliser un serveur payé en continu.
Le vrai motif d’auto-hébergement en 2023 : la confidentialité, pas le coût
Sur les projets où l’auto-hébergement reste malgré tout justifié aujourd’hui, la raison n’est presque jamais économique : c’est l’exigence contractuelle ou réglementaire de ne jamais transmettre certaines données à un tiers, notamment sur des secteurs sensibles comme la santé ou le juridique.
Ce que nous recommandons selon le contexte
- Volume faible à moyen, pas d’exigence de confidentialité stricte : API commerciale, plus rapide et moins chère à ce stade.
- Exigence contractuelle de confidentialité, budget permettant un GPU dédié : auto-hébergement justifié malgré le coût.
- Tâches de fond non urgentes, comme la modération de commentaires en asynchrone : l’auto-hébergement sur CPU redevient viable, la latence n’étant plus un problème.
En 2023, l’auto-hébergement d’un LLM ouvert résout un problème de confidentialité, rarement un problème de coût, sauf à des volumes que peu de sites WordPress atteignent.
Notre verdict
Faisable, mais pas encore pertinent par défaut pour la majorité des projets WordPress que nous accompagnons. Nous recommandons de partir d’une API commerciale, et de ne basculer vers l’auto-hébergement que lorsqu’une contrainte précise — confidentialité contractuelle ou volume d’appels très élevé — le justifie clairement.
