Réserver

WordPress et l’IA en 2026 : l’Abilities API, l’adaptateur MCP et l’IA dans le cœur

par Francis Rozange | Oct 2, 2026 | WordPress

A glass building with many small doors, only some opening to glowing orbs

Début octobre 2025, une option d’AI Engine, un plugin d’IA alors installé sur plus de 100 000 sites WordPress, plaçait la clé d’accès de son serveur MCP dans l’adresse même de ses routes. Ces routes apparaissaient dans l’index public de l’API REST du site. Sur les sites qui avaient coché cette option, n’importe qui pouvait lire la clé, et cette clé ouvrait le site avec les droits de l’administrateur.

Cet épisode, corrigé en quelques semaines, résume l’enjeu du moment. Les agents d’IA ne se contentent plus de rédiger du texte : ils peuvent agir sur un site, créer des contenus, modifier des réglages, gérer des utilisateurs. WordPress s’est doté en 2025 et 2026 d’une façon officielle de les laisser entrer. Encore faut-il savoir ce qu’elle est, ce qui est réellement dans le cœur, et ce qui ne l’est pas.

Ce guide présente les briques construites par l’équipe Core AI de WordPress : l’Abilities API, le client d’IA, l’écran des connecteurs, l’adaptateur MCP et le plugin AI. Pour chacune, son état en octobre 2026, ce qu’elle change pour un propriétaire de site, et les questions de sécurité qu’elle pose.

Ce que « l’IA dans le cœur » veut dire en octobre 2026

De l’infrastructure, pas des fonctions

L’Abilities API est arrivée dans WordPress 6.9, en décembre 2025. Le client d’IA et l’écran des connecteurs sont arrivés dans la 7.0, en mai 2026. La 7.1 a affiné l’Abilities API. Mais une installation par défaut ne montre aucune fonction d’IA visible, n’embarque aucun fournisseur et ne contient aucun serveur MCP. L’équipe Core AI le disait elle-même en juin 2026 : il n’y a toujours pas d’IA visible dans l’interface par défaut.

Autrement dit, WordPress fournit la tuyauterie, et ce sont des plugins qui l’utilisent. Notre guide sur ce qui a changé avec WordPress 7 replace ces briques dans l’ensemble des nouveautés.

Les quatre briques en un coup d’œil

  • L’Abilities API : un registre de ce qu’un site sait faire, dans le cœur depuis 6.9.
  • Le client d’IA et le SDK PHP AI Client : une interface unique pour interroger un modèle, dans le cœur depuis 7.0, avec l’écran des connecteurs.
  • L’adaptateur MCP : un plugin séparé, distribué depuis GitHub, qui ouvre les capacités du site aux agents.
  • Le plugin AI : les fonctions visibles, en expérimentation, sur le répertoire WordPress.org.

L’équipe Core AI et sa feuille de route

De la création à la nouvelle direction

L’équipe Core AI a été annoncée le 27 mai 2025, avec une approche par plugins d’abord, comme l’équipe Performance avant elle. En juillet 2025, James LePage publie son plan : un SDK pour interroger les modèles, l’Abilities API, l’adaptateur MCP et un plugin d’expérimentation. L’ambition affichée est que, dès la 7.0, chacun puisse utiliser et construire des fonctions d’IA.

Le 18 mai 2026, James LePage et Felix Arntz quittent la codirection de l’équipe, tout en restant conseillers, et Jason Adams en prend la tête. Le même message précise que l’adaptateur MCP et le plugin AI restent, pour l’instant, en dehors du cœur.

La 7.2 et la nouvelle règle : prouver avant d’intégrer

La feuille de route de la 7.2, publiée le 18 septembre 2026, rappelle la consigne prudente issue du cycle de la 7.1 : une fonction d’IA doit démontrer son adoption et son utilité réelle avant d’être envisagée pour le cœur. Tous les travaux d’IA prévus, capacités d’écriture, adaptateur MCP à jour, identité des agents, se feront dans le plugin AI, sans garantie d’arriver dans la 7.2.

L’Abilities API : décrire ce qu’un site sait faire

Anatomie d’une capacité

Une capacité, ou « ability », est une unité de fonction qui se décrit elle-même : un nom, un libellé, une description, une catégorie, un schéma des données attendues et renvoyées, une fonction d’exécution et une fonction de vérification des droits. Un agent, le client d’IA ou un autre plugin peuvent ainsi découvrir ce que le site sait faire, et l’appeler proprement.

Voici l’exemple de la note de développement de WordPress 6.9, condensé et complété du drapeau public de la 7.1 et de l’annotation de lecture seule :

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'content-management', array(
        'label'       => __( 'Content Management', 'my-plugin' ),
        'description' => __( 'Abilities for managing and organizing content.', 'my-plugin' ),
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-plugin/get-post-count', array(
        'label'               => __( 'Get Post Count', 'my-plugin' ),
        'description'         => __( 'Retrieves the total number of published posts.', 'my-plugin' ),
        'category'            => 'content-management',
        'input_schema'        => array( 'type' => 'string', 'default' => 'post' ),
        'output_schema'       => array( 'type' => 'integer' ),
        'execute_callback'    => function ( $input ) {
            return (int) wp_count_posts( $input ?? 'post' )->publish;
        },
        'permission_callback' => function () {
            return current_user_can( 'read' );
        },
        'meta'                => array(
            'public'      => true,
            'annotations' => array( 'readonly' => true ),
        ),
    ) );
} );

Une capacité doit être déclarée sur son hook dédié ; en dehors, l’enregistrement échoue. Son nom suit la forme espace/nom-de-la-capacite, en minuscules.

L’API REST et les méthodes HTTP

Les capacités exposées sont disponibles sous l’espace REST wp-abilities/v1, toujours pour un utilisateur authentifié. Le cœur impose une règle utile : une capacité annotée en lecture seule s’appelle en GET, une capacité destructrice et idempotente en DELETE, les autres en POST. Une méthode incorrecte renvoie une erreur 405.

Pour tester la capacité de l’exemple, déclarée en lecture seule, un appel GET suffit, authentifié par un mot de passe d’application, la donnée d’entrée passant en paramètre :

curl -u 'USER:APP_PASSWORD' 'https://example.com/wp-json/wp-abilities/v1/abilities/my-plugin/get-post-count/run?input=page'

Ce que la 7.1 a ajouté

La 7.1 a unifié l’exposition sous un seul drapeau, meta.public, permis de filtrer la liste des capacités, et ajouté des filtres sur tout le cycle d’exécution : avant l’appel, sur les droits, sur le résultat. Une action se déclenche à chaque appel, refusé ou non, ce qui permet une journalisation. La note de développement insiste sur un point : l’exposition n’est pas une autorisation, seule la vérification des droits protège.

Les nouveaux filtres permettent aussi de couper une capacité sans la supprimer, pendant une maintenance par exemple. Cet extrait, simplifié à partir de la note de développement de la 7.1, renvoie une erreur 503 pour une seule capacité :

add_filter( 'wp_pre_execute_ability', function ( $pre, $ability_name ) {
    if ( 'my-plugin/sync-catalog' !== $ability_name ) {
        return $pre;
    }
    return new WP_Error( 'ability_temporarily_unavailable', __( 'Temporarily unavailable.', 'my-plugin' ), array( 'status' => 503 ) );
}, 10, 2 );

Qui déclare déjà des capacités

Le cœur n’en déclare que trois, toutes en lecture : les informations du site, de l’utilisateur connecté et de l’environnement. Les capacités de lecture des contenus et des réglages, proposées en juillet 2026, ne sont disponibles que dans le plugin AI. WooCommerce 10.9, en juin 2026, déclare des capacités officielles pour les produits et les commandes, la suppression d’un produit allant par défaut à la corbeille.

WooCommerce propose aussi, en aperçu pour les développeurs, une intégration MCP à activer explicitement. Sa documentation demande un mot de passe d’application, jamais le mot de passe du compte ni une clé de l’API REST de WooCommerce, et prévient que les opérations sur les commandes et les clients peuvent exposer des données personnelles. À réserver à une copie de la boutique.

Le client d’IA, le SDK PHP et l’écran des connecteurs

Une interface unique pour tous les fournisseurs

Le client d’IA du cœur repose sur un SDK indépendant de WordPress, PHP AI Client, enveloppé par une couche propre à WordPress. Un plugin exprime ses préférences de modèle, mais c’est le propriétaire du site, par les fournisseurs qu’il a configurés, qui décide. Le plugin vérifie d’abord qu’une fonction est disponible, sans appel payant :

$builder = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' );
if ( $builder->is_supported_for_text_generation() ) {
    $text = $builder->generate_text();
    if ( ! is_wp_error( $text ) ) {
        echo wp_kses_post( $text );
    }
}

La note de développement le répète : il ne faut jamais supposer qu’une fonction d’IA est disponible parce que WordPress 7.0 est installé. Le SDK autonome a depuis évolué, avec la génération de vecteurs pour la recherche sémantique en juillet 2026, mais le cœur embarque toujours sa version 1.3.1.

L’écran des connecteurs et l’endroit où vit votre clé

L’écran des connecteurs, dans les Réglages, met en avant Anthropic, Google et OpenAI ; chacun demande d’installer le plugin du fournisseur. Les plugins officiels de ces trois fournisseurs dépassent chacun les 50 000 installations actives en octobre 2026. Des connecteurs communautaires existent aussi, dont Ollama pour un modèle local, sans clé.

La clé d’API est cherchée dans une variable d’environnement, puis une constante PHP, puis la base de données. Or une clé en base n’est pas chiffrée, seulement masquée à l’écran : elle se retrouve dans chaque sauvegarde et chaque copie du site. Préférez une constante dans wp-config.php ou une variable d’environnement. Une API de secrets est proposée pour la 7.2.

Couper l’IA là où elle n’a rien à faire

Deux leviers existent depuis la 7.0. La constante suivante désactive le support de l’IA sur tout le site :

define( 'WP_AI_SUPPORT', false );

Plus finement, le filtre wp_ai_client_prevent_prompt bloque les requêtes selon le contexte, par exemple pour tout utilisateur qui n’est pas administrateur. Sur un site d’entreprise soumis à des règles de confidentialité, c’est la première ligne de défense.

MCP et l’adaptateur MCP : laisser entrer les agents

MCP en bref

Le Model Context Protocol est un standard ouvert qui permet à un assistant d’IA d’utiliser des outils, de lire des ressources et de suivre des modèles de requêtes fournis par un serveur. La connexion se fait soit en local, par l’entrée et la sortie standard d’un programme, soit à distance, par HTTP. La dernière version de la spécification date du 28 juillet 2026.

Le serveur par défaut et ses trois outils

L’adaptateur MCP de WordPress transforme les capacités en outils MCP. À l’activation, il crée un serveur par défaut qui expose trois outils génériques : découvrir les capacités, obtenir la description de l’une d’elles, l’exécuter. Seules les capacités explicitement publiques sont visibles, et l’outil d’exécution revérifie les droits de la capacité appelée.

Deux contrôles s’enchaînent : celui du transport, qui exige par défaut un utilisateur connecté, puis celui de chaque capacité. En local, l’adaptateur se lance avec WP-CLI, sous l’identité d’un utilisateur précis, comme le montrent nos commandes WP-CLI essentielles :

wp mcp-adapter serve --server=mcp-adapter-default-server --user=mcp-agent

Ici, mcp-agent désigne un compte dédié aux droits limités ; la documentation de l’adaptateur déconseille de lancer le serveur en administrateur sans nécessité.

Se connecter à distance

Pour un agent qui ne tourne pas sur le serveur, la documentation de l’adaptateur passe par un petit relais local publié par Automattic, qui se connecte au site en HTTP. Il accepte OAuth 2.1, des jetons ou des mots de passe d’application.

Mais OAuth suppose que le site dispose d’un serveur d’autorisation : c’est le cas de WordPress.com, pas d’une installation WordPress standard, qui n’en embarque aucun. Sur un site auto-hébergé, l’agent se connecte donc en pratique avec un mot de passe d’application.

Version 0.6.1 : encore un outil de développeur

En octobre 2026, la dernière version de l’adaptateur est la 0.6.1, publiée le 13 août. Elle se télécharge depuis GitHub, pas depuis le répertoire officiel, où sa publication est un objectif du cycle 7.2. La prise en charge de la dernière version de la spécification MCP n’est décrite que dans une version 0.7.0 non publiée. C’est un outil à essayer sur une copie, pas à brancher en production sans précaution.

Le plugin AI, ex-AI Experiments

Ce qu’il fait aujourd’hui

Le plugin officiel, rebaptisé simplement AI en mars 2026, dépasse les 50 000 installations actives. Il propose des fonctions activables une à une : génération de titres, de résumés, de méta-descriptions et de textes alternatifs, génération et retouche d’images, modération et réponses aux commentaires, traduction, classement des contenus.

Il exige au moins un connecteur et votre propre clé d’API ; le plugin est gratuit, l’usage du modèle est facturé par le fournisseur. Il ne fonctionne qu’avec l’éditeur de blocs, et sa propre FAQ recommande de le tester d’abord sur une copie du site.

Les fonctions de gouvernance à activer

Trois expérimentations méritent d’être activées en premier : la journalisation des requêtes d’IA, l’approbation des connecteurs, qui permet à l’administrateur de décider quels plugins peuvent utiliser les fournisseurs configurés, et le chiffrement des clés au repos, qui pallie la limite du cœur.

La fiche du plugin annonce d’autres fonctions à venir, dont un espace d’essai, un assistant de rédaction, un agent capable d’agir sur le site et l’automatisation de tâches. Rien de cela n’est livré en octobre 2026 : jugez le plugin sur ce qu’il fait aujourd’hui, pas sur sa liste d’intentions.

Une porte de verre entrouverte laissant filer un rayon de lumière

Le cas réel : AI Engine et la porte MCP entrouverte

AI Engine, de Jordy Meow, est un plugin de chatbot et d’outils d’IA qui comptait plus de 100 000 installations actives en 2025. Il a été l’un des premiers à offrir un serveur MCP dans WordPress. Son histoire, documentée par Wordfence, par les registres de vulnérabilités et par le journal des modifications du plugin, montre ce qui se joue quand un agent reçoit les clés d’un site.

Mai et juin 2025 : chaque utilisateur connecté, administrateur potentiel

Le 30 avril 2025, AI Engine ajoute le support de MCP, présenté comme une fonction bêta. Il permet à un assistant comme Claude de créer des utilisateurs, de modifier des réglages, d’éditer et de supprimer des articles. Le 21 mai, István Márton, chercheur chez Wordfence, découvre que l’accès au serveur MCP n’exigeait qu’une chose : être connecté. Un simple abonné pouvait l’atteindre.

La vérification facultative par clé se contournait en n’envoyant aucune clé. Avec les outils MCP de gestion des utilisateurs, un abonné pouvait se promouvoir administrateur. Une condition limitait l’exposition : il fallait avoir activé les outils de développement puis le module MCP, désactivés par défaut. L’éditeur répond dans l’heure, et la version 2.8.4 corrige le 18 juin 2025, en réservant l’accès aux administrateurs.

Octobre 2025 : la clé dans l’index public

Quelques mois plus tard, une nouvelle option, désactivée par défaut, place la clé d’accès dans l’adresse des routes MCP, pour les clients qui ne savent pas envoyer d’en-tête. Mais ces routes sont déclarées sans être masquées de l’index public de l’API REST. Sur les sites concernés, n’importe quel visiteur pouvait lire la clé, et cette clé authentifiait comme l’administrateur du site.

Selon Wordfence, la faille lui a été signalée un jour seulement après son introduction, par Emiliano Versini, via son programme de récompenses. La version 3.1.4 la corrige le 19 octobre 2025, en masquant les routes. Wordfence insiste : la correction empêche seulement de nouvelles fuites, et la seule solution sûre est de changer la clé. Aucune exploitation n’a été signalée dans les sources consultées.

2026 : trois nouveaux correctifs et un autre modèle

En 2026, trois autres corrections touchent le même périmètre. En mai, la connexion OAuth que le plugin venait d’ajouter, en version 3.4.9, ouvrait les outils MCP à tout jeton OAuth valide sans vérifier que son titulaire était administrateur : un abonné pouvait de nouveau se hisser administrateur, jusqu’à la version 3.5.0, publiée quatre jours plus tard.

Deux autres suivent : des outils MCP de gestion des utilisateurs qui ne vérifiaient pas correctement les droits sur un multisite, puis des clés visibles par un éditeur dans le code de la page. Le plugin a changé d’approche : connexion par OAuth pour les applications de bureau, sans clé partagée, approbation demandée avant toute modification lancée depuis son espace de travail intégré, et refus d’exécuter du code PHP arbitraire, une fonction qu’il juge dangereuse par nature.

Ce que la pile officielle fait autrement, et ce qui lui manque

Un serveur MCP dans WordPress est une route REST : sa vérification des droits est tout son périmètre, et « être connecté » n’est pas un droit. Une clé statique qui donne les droits de l’administrateur est un mot de passe administrateur : tout ce qui peut l’afficher, index REST, adresse, journal, est une fuite. Dès sa version de mars 2025, antérieure aux deux failles, la spécification MCP impose d’envoyer le jeton d’accès dans l’en-tête Authorization et interdit de le placer dans la chaîne de requête de l’adresse.

La pile officielle répond à plusieurs de ces points par conception : capacités privées par défaut, vérification des droits pour chacune, double contrôle dans l’adaptateur, connexion sous un vrai compte. Mais elle ne règle pas encore l’identité des agents ni la limitation des droits d’une clé. Même le plugin AI officiel a publié cinq avis de sécurité, dont une capacité qui permettait à un auteur de faire interroger des adresses internes par le serveur.

Permissions et authentification des agents

Les mots de passe d’application : pratiques, mais sans limite

Pour un agent distant sur un site auto-hébergé, la méthode documentée est le mot de passe d’application, disponible depuis WordPress 5.6. Il se révoque à tout moment depuis le profil de l’utilisateur, avec la date et l’adresse IP de dernière utilisation. Mais il porte toutes les capacités de son utilisateur : la possibilité de limiter sa portée figure depuis 2020 dans les évolutions futures, sans être arrivée.

Si vous n’en avez pas l’usage, vous pouvez les désactiver :

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Un utilisateur dédié par agent, en lecture d’abord

Le blog officiel des développeurs WordPress donne la règle : un client MCP agit comme un utilisateur connecté, il fait donc partie de la surface de votre application. Créez un compte dédié pour chaque agent, avec le rôle le plus faible possible, comme l’explique notre guide des rôles utilisateurs WordPress. Sur un point d’accès HTTP exposé à Internet, privilégiez les capacités en lecture seule, et surveillez et journalisez l’usage.

Ce que dit la spécification MCP

La spécification MCP de juillet 2026 rend l’autorisation facultative, mais recommande un flux fondé sur OAuth 2.1 pour les connexions HTTP. Elle demande à l’application qui pilote l’agent d’obtenir le consentement explicite de l’utilisateur avant d’appeler un outil, et précise que les annotations d’un outil, comme « lecture seule », ne doivent pas être crues sur parole si le serveur n’est pas de confiance. Un agent bien conçu demande donc avant d’agir.

Côté WordPress, la feuille de route de la 7.2 prévoit un courriel d’alerte quand un mot de passe d’application est créé, et une nouvelle authentification avant les actions sensibles. Ni l’un ni l’autre n’est livré en octobre 2026.

Ce qui peut mal tourner

  • Une capacité qui va chercher une adresse : elle peut servir à interroger des services internes du serveur.
  • Une capacité qui écrit des métadonnées : elle a permis, dans le plugin AI, à un auteur de supprimer les fichiers médias d’autres utilisateurs.
  • Le coût : une fonction appelée sans contrôle consomme des crédits d’API payants.
  • L’injection de consignes : un contenu malveillant renvoyé par une capacité peut détourner l’agent ; la proposition de capacités du cœur la déclare hors de son périmètre.
  • L’absence d’identité : les actions d’un agent sont attribuées à l’humain dont il emprunte les identifiants.

Ces risques s’ajoutent aux mesures de base de notre guide pour sécuriser WordPress.

L’IA côté hébergeurs

WordPress.com : la lecture, puis l’écriture avec approbation

WordPress.com a ouvert MCP en lecture seule sur ses offres payantes en octobre 2025, ajouté une connexion OAuth 2.1 en janvier 2026, puis l’écriture en mars 2026. Les garde-fous sont explicites : chaque changement demande votre approbation, les nouveaux articles sont créés en brouillon, les suppressions passent par la corbeille quand c’est possible, celle d’une catégorie ou d’une étiquette, définitive, exigeant une confirmation supplémentaire, les droits des rôles sont respectés, et chaque opération peut être activée séparément.

Les hébergeurs comme fournisseurs d’IA

L’équipe Core AI a publié en décembre 2025 un appel aux hébergeurs. Selon elle, le principal frein est que chaque utilisateur doit apporter sa propre clé d’API. Elle propose que les hébergeurs déclarent leur propre fournisseur, pour que les fonctions des plugins marchent sans configuration. WordPress.com et DreamHost travaillaient en ce sens, selon le bilan de l’équipe, mais aucune offre de ce type n’était documentée publiquement chez DreamHost au moment où nous écrivons.

WordPress VIP, WP Engine et Pressable

WordPress VIP propose depuis juillet 2026 un accès MCP sécurisé, fermé par défaut, avec un journal des appels et un interrupteur général. WP Engine active par défaut un serveur MCP en lecture sur les contenus publics de ses offres concernées, qu’il faut désactiver si vous n’en voulez pas. Pressable propose un serveur MCP pour l’hébergement lui-même, capable de lancer des commandes WP-CLI sur plusieurs sites à la fois. Notre comparatif des hébergements WordPress aide à situer ces offres.

Ce qu’on peut essayer aujourd’hui, ce qu’il faut attendre

Brique État en octobre 2026 À essayer ? Condition
Abilities API Cœur depuis 6.9, affinée en 7.1 Oui, pour les développeurs Vraie vérification des droits
Client d’IA et connecteurs Cœur depuis 7.0 Oui Clé hors de la base
Plugin AI Expérimental, version 1.3 Oui, sur une copie Journalisation et approbations actives
Adaptateur MCP 0.6.1, hors répertoire En local ou sur une copie Compte dédié, lecture seule
Capacités d’écriture du cœur En discussion Non Attendre la 7.2 ou plus
Identité des agents, mots de passe limités Non livrés Non Suivre la feuille de route
API de secrets Proposée pour la 7.2 Non Constantes en attendant

Questions fréquentes

Faut-il WordPress 7.0 pour utiliser l’IA ?

Pour le client d’IA et l’écran des connecteurs, oui. L’Abilities API existe depuis la 6.9 ; les plugins de fournisseurs officiels s’installent dès la 6.9, mais n’y fonctionnent qu’avec le paquet PHP AI Client installé à part, ce qui reste une affaire de développeur. Le plugin AI exige la 7.0.

WordPress envoie-t-il mes contenus à une IA par défaut ?

Non. Sans plugin de fournisseur, sans clé et sans fonction activée, rien ne part. C’est vous qui branchez un fournisseur et activez des fonctions.

L’adaptateur MCP est-il sûr en production ?

Il est conçu prudemment, capacités privées par défaut et double contrôle des droits, mais il reste en version 0.x, hors du répertoire. En production, réservez-le à un compte dédié aux droits limités et à des capacités en lecture seule.

Peut-on utiliser un modèle local ?

Oui, grâce à des connecteurs communautaires comme celui d’Ollama, qui ne demande pas de clé. Le modèle tourne alors sur votre machine ou votre serveur.

Les mots de passe d’application limitent-ils ce qu’un agent peut faire ?

Non. Ils portent toutes les capacités de leur utilisateur. C’est le rôle du compte qui fixe la limite, d’où l’intérêt d’un compte dédié.

Conclusion

En octobre 2026, l’IA dans WordPress est une infrastructure solide mais discrète : une Abilities API pour décrire ce que fait un site, un client d’IA indépendant des fournisseurs, un écran de connecteurs, un adaptateur MCP encore jeune et un plugin d’expérimentation. Rien ne s’active seul, et c’est une bonne nouvelle.

L’histoire d’AI Engine rappelle ce qui compte vraiment quand un agent agit sur un site : des droits vérifiés à chaque appel, des clés qui ne fuient pas, un compte dédié pour chaque agent. Essayez sur une copie, en lecture d’abord, et attendez l’identité des agents avant de leur confier l’écriture en production.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier