Le 4 novembre 2026, j’ai assisté à une présentation technique de Cohesivo v6, la prochaine évolution d’Ibexa DXP. Derrière le changement de nom, l’éditeur présente une continuité fonctionnelle pour les équipes éditoriales, mais aussi une modernisation importante du socle et une orientation très nette vers les agents IA.
Voici mon retour d’expérience sur les annonces principales, les opportunités techniques et les points de vigilance avant d’envisager une migration depuis Ibexa 4.6.
Ibexa DXP devient Cohesivo
Le message de l’éditeur est clair : Cohesivo n’est pas annoncé comme un remplacement complet d’Ibexa, mais comme son prochain chapitre. Les concepts éditoriaux et les habitudes de travail doivent rester reconnaissables. Côté développement, les namespaces, packages et configurations conserveraient largement le nom Ibexa.
Trois modes d’exploitation restent proposés :
- SaaS : la plateforme est exploitée par l’éditeur ;
- PaaS : l’infrastructure est fournie par l’éditeur et exploitée par le partenaire ;
- on-premise : le client fournit et opère l’ensemble de l’infrastructure.
Les anciennes éditions Headless, Experience et Commerce convergent vers un produit Cohesivo commun. Le Commerce SDK vient ensuite compléter la plateforme lorsque le projet en a besoin.
Une plateforme construite pour les agents
La nouveauté la plus visible est l’intégration des agents IA au cœur de l’expérience. L’AI Assistant de l’AdminUI devient le point d’entrée vers un orchestrateur capable de sélectionner un agent spécialisé selon la demande.
Les rôles présentés couvrent notamment :
- l’architecture et la maintenance du modèle de contenu ;
- la construction et l’ajustement des pages ;
- la traduction en volume ;
- l’analyse SEO et la qualité éditoriale ;
- la taxonomie et la cohérence des classifications ;
- l’exploration du référentiel de contenus.
Le principe de gouvernance annoncé est essentiel : les agents proposent, les personnes approuvent. Chaque outil s’exécute dans le modèle de permissions de l’utilisateur représenté par l’agent.
Un serveur MCP intégré
Cohesivo doit embarquer un serveur MCP exposant environ cent outils sur les contenus, les modèles, les langues, les emplacements, les workflows, les assets et le Page Builder. Il pourra être utilisé par l’assistant natif, par IAMP ou par un agent externe compatible MCP.
Cette approche est intéressante parce qu’elle évite de créer une API spéciale pour chaque assistant. Une nouvelle capacité doit être livrée avec son API et son outil agent. L’ambition affichée est qu’une opération réalisable par un éditeur puisse également être exécutée par une intégration ou un agent, dans le respect des mêmes permissions.
Un saut technique majeur
Cohesivo v6 ne constitue pas une mise à jour mineure du socle. Les versions annoncées sont :
- PHP 8.5 ou supérieur ;
- Symfony 8.1, puis le prochain Symfony LTS ;
- Doctrine DBAL 4 et ORM 3 ;
- les composants Symfony habituels : conteneur de services, Twig, Messenger et profiler.
Les services présentés comprennent notamment MariaDB 11.8 ou 12.3 LTS, Solr 9.10 ou 10+, PostgreSQL 16 à 18, Elasticsearch 8.19 ou 9.x, Redis 8.4+, Valkey 9+ et Varnish 8.
Pour un projet encore sous Ibexa 4.6 et Symfony 5.4, la migration devra donc être considérée comme un programme technique complet. Les bundles internes, extensions tierces, événements Symfony, dépendances Composer et développements historiques devront être inventoriés et testés.
Doctrine Migrations pour toutes les évolutions de schéma
Chaque changement de base de données de v6 doit être distribué sous forme de migration Doctrine versionnée avec le code. Une mise à niveau exécute successivement les migrations du produit, celles des extensions et celles du projet.
C’est une évolution bienvenue : elle rapproche la maintenance du produit des pratiques Symfony standards et améliore la traçabilité. Elle impose en contrepartie de clarifier les scripts SQL historiques et les mécanismes de déploiement applicatif propres à chaque projet.
Publication asynchrone, REST et webhooks
Les publications lourdes pourront être envoyées dans une file Messenger. L’éditeur continue ainsi à travailler pendant la publication d’un grand sous-arbre. Doctrine, Redis, Valkey ou PostgreSQL pourront servir de transport.
Les nouveaux endpoints REST seront développés avec API Platform et documentés en OpenAPI. Les endpoints REST existants sont annoncés comme compatibles afin de préserver les intégrations. Des webhooks permettront également de pousser les événements de contenu vers IAMP, Ibexa Connect ou des systèmes tiers, avec filtrage possible par type d’événement et sous-arbre.
Page Builder et projets headless
Le Page Builder doit pouvoir travailler avec un front headless. L’éditeur compose toujours visuellement la page, tandis que la prévisualisation est rendue par le front du projet. La structure de page est disponible par REST et un protocole versionné assure la communication entre le Page Builder et l’application.
C’est une ouverture intéressante pour les architectures découplées. Elle ne signifie toutefois pas qu’un projet existant doit devenir headless : ce choix doit rester guidé par les besoins métier, les performances, le référencement et le coût d’exploitation.
Traductions et qualité du contenu
La limite historique de 62 langues disparaît. Une nouvelle couche de données doit mesurer la complétude des champs, la fraîcheur des contenus et la couverture des traductions. Ces informations pourront être interrogées par sous-arbre, type de contenu et langue via REST, GraphQL ou MCP.
La gestion des traductions pourra se connecter à plusieurs services de traduction automatique ou fournisseurs d’IA. Les traducteurs disposeront d’une vue source-cible, et les textes générés resteront des brouillons à relire avant publication. Les traitements en masse seront accessibles depuis l’AdminUI ou la ligne de commande.
Mon avis après cette présentation
La direction est cohérente. Cohesivo v6 modernise fortement la base technique tout en essayant de préserver les concepts d’Ibexa. L’adoption de Doctrine Migrations, API Platform, OpenAPI, Messenger, des webhooks et de MCP offre un cadre plus standard aux intégrateurs Symfony.
Les agents peuvent apporter une vraie valeur pour les opérations répétitives : audit de qualité, traduction, classification, exploration du référentiel ou préparation de pages. Leur intérêt dépendra toutefois de la gouvernance, de la traçabilité, du coût, de la localisation des données et de la capacité à fonctionner dans les différents modes d’hébergement.
Pour un parc Ibexa 4.6 important, la bonne stratégie n’est pas de lancer immédiatement une migration globale. Il faut d’abord :
- obtenir le chemin de migration officiellement supporté ;
- dresser une matrice de compatibilité des bundles et extensions ;
- identifier toutes les API dépréciées ;
- construire un prototype sur un périmètre représentatif ;
- tester les contenus, les droits, Solr, Messenger, Page Builder et les intégrations ;
- mesurer les coûts techniques et opérationnels avant de décider.
Conclusion
Cohesivo v6 est bien davantage qu’un changement de marque. La plateforme combine un socle Symfony profondément renouvelé, de nouvelles surfaces d’intégration et une architecture conçue pour les agents. Les annonces sont prometteuses, mais la distance avec Ibexa 4.6 impose une préparation sérieuse et un prototype réaliste avant toute trajectoire de migration.
