Comment faire fonctionner les fonctionnalités d’IA de WordPress avec un modèle local grâce à Ollama

WordPress 7.0 inclut un AI Client, la bibliothèque PHP derrière wp_ai_client_prompt(), ainsi qu’un écran Réglages, Connecteurs où se branchent les fournisseurs d’IA. Installez l’extension AI Provider for Ollama et ce client peut parler à un modèle qui tourne sur votre propre ordinateur ou serveur grâce à Ollama. Vos requêtes ne quittent jamais votre réseau et personne ne vous facture au jeton.

La configuration est courte : lancer Ollama, télécharger un modèle, activer l’extension, définir l’adresse de l’hôte, exécuter une requête de test. Presque toutes les questions du forum de soutien de l’extension se résument à WordPress qui n’arrive pas à joindre Ollama. La deuxième moitié de cet article passe donc en revue ces échecs, avec les messages exacts que vous verrez.

De quoi avez-vous besoin?

• Ollama avec un modèle téléchargé, par exemple ollama pull llama3.2. Un modèle demande à peu près sa taille de téléchargement en mémoire libre, et il n’est rapide que s’il tient dans le GPU; ollama ps indique où un modèle chargé a atterri. Commencez petit.
• WordPress 7.0 ou plus récent. Les étapes ci-dessous ont été vérifiées sur la version 7.1.
• L’extension AI Provider for Ollama de WordPress.org, par Fueled, version 1.3.0 (13 octobre 2026), code sur GitHub sous Fueled/ai-provider-for-ollama. Elle exige WordPress 7.0 et PHP 7.4, et communique avec les points de terminaison /api/tags, /api/show et /v1/chat/completions (compatible OpenAI) d’Ollama. Aucune clé d’API pour un serveur local.
• Facultatif : l’extension AI de WordPress.org (1.4.0, exige WordPress 7.0.3) pour des fonctions prêtes à l’emploi comme le texte alternatif, les extraits et les titres.

Comment connecter WordPress à Ollama?

1. Installez et activez l’extension depuis Extensions, Ajouter. Si vous la prenez sur GitHub, utilisez le zip de la version publiée, pas le code source : le code source n’a pas de dossier vendor, et l’extension vous demande alors d’exécuter composer install.
2. Ouvrez Réglages, Ollama. Le Host URL est par défaut http://localhost:11434, où localhost est la machine qui exécute PHP. Entrez l’adresse de base sans /v1, sinon chaque requête va à /v1/api/tags et Ollama répond 404. La liste Available Models est récupérée en direct; « AI provider not configured » signifie que WordPress ne peut pas encore joindre Ollama. Une variable d’environnement OLLAMA_HOST visible par PHP remplace le champ, et elle doit inclure http://.

3. Vérifiez Réglages, Connecteurs. La carte Ollama affiche Connected dès que WordPress peut récupérer la liste des modèles, sans qu’aucune clé soit enregistrée. Laissez le champ de clé d’API vide pour un serveur local : l’extension enregistre une clé vide, WordPress envoie Authorization: Bearer sans rien après, et Ollama l’ignore. Pour Ollama Cloud, réglez le Host URL à https://ollama.com et enregistrez votre clé ici, ou définissez une constante ou une variable d’environnement OLLAMA_API_KEY. Si vous cliquez sur Edit sur la carte, vous verrez un champ de clé vide avec la note « Your API key is stored securely » et un lien Remove and replace, même si aucune clé n’est enregistrée. Ignorez les deux et laissez le champ vide.

4. Choisissez un modèle. Dans l’extension AI, ouvrez Réglages, AI, cliquez sur l’icône d’outil en haut à droite (un menu à trois points avant la version 1.4.0) et activez Model selection; chaque fonction reçoit alors des listes déroulantes Provider et Model. Dans le code, passez à using_model_preference() le nom exactement comme ollama ls l’affiche, étiquette comprise : llama3.2:latest, pas llama3.2. Sans préférence, ou avec un nom qui ne correspond pas, le client prend discrètement le premier modèle par ordre alphabétique.
5. Exécutez une requête de test. Enregistrez le fichier ci-dessous et lancez wp eval-file ollama-check.php. Sans WP-CLI, activez la génération d’extraits dans l’extension AI et utilisez-la dans l’éditeur.

<?php
/**
 * Quick Ollama check. Save as ollama-check.php, then run:
 * wp eval-file ollama-check.php
 */
$result = wp_ai_client_prompt( 'Reply with one word: ready.' )
	->using_provider( 'ollama' )
	->using_model_preference( 'llama3.2:latest' )
	->generate_text();

if ( is_wp_error( $result ) ) {
	WP_CLI::error( $result->get_error_message() );
}

WP_CLI::success( $result );

Pourquoi WordPress dit-il que le fournisseur n’est pas configuré?

Deux messages veulent dire la même chose : « AI provider not configured – ensure Ollama is running or you have valid API credentials. » sur la page de réglages, et le WP_Error No models found for provider "ollama" that support text_generation for this prompt. renvoyé par une requête. Les deux signifient qu’une seule requête a échoué, GET /api/tags sur votre hôte Ollama, et que l’AI Client cache la vraie erreur réseau derrière une liste de modèles vide. Cette commande d’une ligne envoie la même requête par la couche HTTP de WordPress et affiche la vraie erreur, ou la liste des modèles :

wp eval '$r = wp_safe_remote_get( getenv( "OLLAMA_HOST" ) . "/api/tags" ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_body( $r );'

« cURL error 7: Failed to connect » signifie que rien n’écoute à cette adresse depuis l’endroit où PHP s’exécute. « A valid URL was not provided. » signifie que le nom d’hôte ne se résout pas depuis le serveur, ou que l’adresse n’a pas de http://. « User has blocked requests through HTTP » signifie que wp-config.php définit WP_HTTP_BLOCK_EXTERNAL; localhost est exempté, tout autre hôte doit être ajouté à WP_ACCESSIBLE_HOSTS.

WordPress s’exécute dans Docker ou une machine virtuelle

Dans un conteneur, localhost désigne le conteneur lui-même, c’est pourquoi wp-env, DDEV et les outils du genre ne voient pas l’instance d’Ollama installée sur votre poste. Réglez l’URL de l’hôte à http://host.docker.internal:11434. Docker Desktop résout ce nom vers votre machine; sur un hôte Linux avec Docker Engine, ajoutez-le avec --add-host host.docker.internal:host-gateway sur docker run ou avec l’entrée extra_hosts équivalente dans Compose. Si le nom se résout mais que la connexion est refusée, c’est qu’Ollama écoute seulement sur 127.0.0.1, son réglage par défaut. Définissez OLLAMA_HOST=0.0.0.0:11434 là où Ollama s’exécute, puis redémarrez-le; la FAQ d’Ollama explique comment faire (launchctl setenv sur macOS, systemctl edit ollama.service sur Linux). Autorisez le port 11434 dans tout pare-feu situé entre les deux.

Un site en production ne peut pas joindre Ollama sur votre portable

La requête part de PHP, sur le serveur web, et votre portable derrière un routeur domestique n’est pas joignable à partir de là. Faites tourner Ollama sur le serveur, ou sur une machine qu’il peut atteindre, comme un serveur GPU dans le même réseau privé, ou intégrez votre machine à ce réseau avec un VPN ou un tunnel. Protégez tout ce que vous exposez : Ollama ignore les clés d’API sur un serveur autohébergé, alors placez devant un proxy inverse qui exige l’en-tête Authorization: Bearer, que WordPress remplit à chaque requête avec la clé enregistrée dans l’écran Connectors.

La vérification de la clé échoue dans l’écran Connectors

Quand vous enregistrez une clé pour un fournisseur d’IA, le cœur de WordPress la valide d’abord : il la transmet au fournisseur et lance la vérification de disponibilité, qui, pour Ollama, est GET /api/tags avec Authorization: Bearer your-key. Toute réponse autre qu’un succès efface la clé et affiche « It was not possible to connect to the provider using this key. » Pour un serveur local, n’entrez aucune clé; si vous en entrez une et que la vérification échoue, le problème vient de la connexion, pas de la clé. Derrière votre propre proxy, celui-ci doit accepter cet unique en-tête et ne rien demander de plus : un commentateur de la note de développement sur l’API Connectors avait un serveur llama derrière une authentification qui exigeait des en-têtes supplémentaires, et la vérification ne peut pas passer dans ce cas.

Les gros modèles dépassent le délai

WordPress ne fait pas de diffusion en continu : il envoie la requête et attend la réponse complète, et le plugin accorde 60 secondes à une requête de génération (10 pour la liste des modèles). Un modèle lent, ou la première requête après qu’Ollama a déchargé le modèle (après cinq minutes d’inactivité par défaut, voir OLLAMA_KEEP_ALIVE), se termine par « cURL error 28: Operation timed out ». La version 1.3.0 a ajouté un filtre pour cela; le plus simple est de le placer dans un plugin à chargement obligatoire (mu-plugin) :

<?php
/**
 * Plugin Name: Ollama timeouts
 * Description: Gives a slow local model up to three minutes to answer.
 */
add_filter( 'ai_provider_for_ollama_request_timeout', function () {
	return 180.0;
} );

Vérifiez ensuite ce qui se trouve devant PHP : le fastcgi_read_timeout de nginx est de 60 secondes par défaut, et les hébergeurs gérés ont leurs propres limites. Il existe aussi un filtre pour le délai de connexion, mais l’adaptateur HTTP de WordPress ne transmet que le délai global.

Un modèle manque dans la liste

Exécutez ollama ls sur l’instance à laquelle WordPress se connecte; un conteneur Ollama a son propre espace de stockage des modèles, distinct de celui de l’application de bureau. WordPress filtre aussi la liste : le plugin interroge /api/show pour connaître les capacités de chaque modèle et ne garde que ceux qui indiquent la complétion (ou la génération d’images). Les modèles d’embeddings uniquement, comme nomic-embed-text, sont exclus volontairement dans WordPress 7.1, parce que l’AI Client intégré au cœur (1.3.1) ne prend pas encore en charge les embeddings.

Quand un modèle local est-il pertinent?

Le local gagne quand le contenu est sensible, quand la tâche est petite et fréquente, ou quand vous développez et ne voulez pas payer pour chaque essai. L’infonuagique gagne quand la qualité compte plus que la destination du texte, ou quand le serveur n’a pas de GPU. J’ai écrit davantage sur la façon de s’appuyer sur ces outils dans is AI bad for developers.

Commencez par le plus petit modèle qui fait le travail, faites réussir la requête de test, puis branchez-y les fonctions du plugin d’IA. Gardez la commande d’une ligne à portée de main pour le jour où une reconstruction Docker ou un déménagement de serveur brisera la connexion.