Rendre votre contenu prêt pour l'IA sans changer de CMS

Il y a actuellement une narration qui circule dans le monde des CMS, et elle ressemble à peu près à ceci : « Si vous voulez du contenu prêt pour l'IA, vous avez besoin de l'approche de contenu structuré de Sanity. » Et regardez, le lac de contenu de Sanity et ses intégrations IA alimentées par GROQ sont vraiment impressionnantes. Mais voilà -- la plupart des équipes ne peuvent pas simplement abandonner leur CMS existant. Vous avez des années de contenu dans WordPress. La couche de données de votre application vit dans Supabase. Vous venez de terminer une migration vers Payload CMS il y a six mois. L'idée d'une autre migration vous donne le vertige.

Bonne nouvelle : vous n'avez pas besoin de changer. Vous avez besoin de penser différemment à la façon dont votre contenu est structuré, stocké et exposé. J'ai passé l'année dernière à aider des équipes à adapter leurs piles existantes pour la consommation par l'IA, et les modèles sont étonnamment cohérents quel que soit le CMS ou la base de données que vous exécutez. Permettez-moi de vous en faire la visite.

Table des matières

Ce que « Contenu prêt pour l'IA » signifie réellement

Avant de devenir tactiques, clarifions ce dont nous parlons réellement. « Contenu prêt pour l'IA » n'est pas un buzz marketing (bon, c'est le cas, mais il y a de la substance dessous). Cela signifie que votre contenu répond à trois critères :

  1. Structure analysable par machine -- Les modèles d'IA peuvent extraire fiablement le sens de votre contenu sans deviner le contexte
  2. Métadonnées enrichies -- Chaque élément de contenu porte suffisamment d'informations sémantiques pour qu'une IA puisse comprendre les relations, l'intention et le contexte
  3. Accessibilité via API -- Le contenu est disponible via des interfaces programmatiques que les agents IA, les pipelines RAG et l'appel d'outils LLM peuvent consommer

C'est tout. Remarquez ce qui ne figure pas sur la liste : un fournisseur spécifique. Ce sont des modèles architecturaux, pas des fonctionnalités de produit.

Le spectre d'intelligence du contenu

Pensez à la préparation du contenu pour l'IA sur un spectre :

Niveau Description Exemple
0 Blob HTML Article WordPress avec styles inline et médias mélangés
1 Séparation des préoccupations HTML propre avec balisage de données structurées
2 Structure au niveau du champ Contenu divisé en champs typés (titre, résumé, corps, auteur)
3 Relations sémantiques Contenu avec références explicites, taxonomies et liens d'entités
4 Natif pour l'IA Contenu avec plongements, annotations sémantiques et intention lisible par machine

Le modèle de contenu structuré de Sanity vous pousse vers les niveaux 3-4 par défaut. Mais chaque CMS peut atteindre le niveau 3, et avec une infrastructure supplémentaire, le niveau 4.

Pourquoi Sanity reçoit toute l'attention

Donnons crédit où c'est dû. L'approche de Sanity en matière de contenu structuré est véritablement bien conçue pour les cas d'usage de l'IA :

  • Portable Text stocke le texte enrichi comme un AST JSON plutôt que HTML, ce qui le rend trivial à analyser par programme
  • Les requêtes GROQ retournent exactement la forme de données dont vous avez besoin, ce qui correspond parfaitement aux fenêtres de contexte LLM
  • Content Lake traite le contenu comme un graphe de documents typés avec des références explicites
  • Leurs intégrations du SDK IA en 2025 permettent l'appel direct d'outils depuis les LLM vers des requêtes de contenu

Mais voici ce que les évangélistes de Sanity ne mentionnent pas : ces avantages sont des modèles architecturaux, pas de la magie propriétaire. Vous pouvez implémenter chacun d'eux dans votre pile existante. Cela demande juste une conception intentionnelle.

La vraie question n'est pas « dois-je basculer vers Sanity ? » C'est « comment appliquer les principes de contenu structuré là où je suis déjà ? »

Structurer le contenu pour l'IA dans WordPress

WordPress alimente quelque chose comme 43 % du web en 2025. Si vous exécutez WordPress, vous êtes en bonne compagnie, et vous avez plus d'options que vous ne le penseriez.

Étape 1 : Arrêtez d'utiliser l'éditeur classique pour tout

L'éditeur de blocs Gutenberg stocke déjà le contenu en tant que blocs structurés. Chaque bloc a un type, des attributs et du contenu. C'est plus proche du Portable Text de Sanity que ce que la plupart des gens réalisent.

{
  "blockName": "core/paragraph",
  "attrs": {},
  "innerBlocks": [],
  "innerHTML": "<p>Ceci est du contenu structuré, pas seulement du HTML.</p>",
  "innerContent": ["<p>Ceci est du contenu structuré, pas seulement du HTML.</p>"]
}

Les données de bloc sont stockées en tant que commentaires sérialisés dans post_content, mais vous pouvez les analyser par programme :

$blocks = parse_blocks($post->post_content);
$structured = array_map(function($block) {
    return [
        'type' => $block['blockName'],
        'attributes' => $block['attrs'],
        'content' => strip_tags($block['innerHTML']),
    ];
}, array_filter($blocks, fn($b) => $b['blockName'] !== null));

Étape 2 : Investir dans des champs personnalisés et des taxonomies

Advanced Custom Fields (ACF) ou Meta Box vous donnent une structure de contenu de niveau 2-3. Mais vous devez être intentionnel à ce sujet. N'ajoutez pas simplement des champs -- concevez un modèle de contenu.

// Enregistrer un type de contenu structuré pour la consommation par l'IA
register_post_type('knowledge_article', [
    'supports' => ['title', 'custom-fields'],
    'show_in_rest' => true, // Critique pour l'accès à l'API
]);

// Définir les champs sémantiques
acf_add_local_field_group([
    'title' => 'AI-Ready Content Fields',
    'fields' => [
        ['key' => 'summary', 'label' => 'Summary', 'type' => 'textarea'],
        ['key' => 'key_concepts', 'label' => 'Key Concepts', 'type' => 'taxonomy', 'taxonomy' => 'concept'],
        ['key' => 'content_intent', 'label' => 'Content Intent', 'type' => 'select', 'choices' => [
            'informational' => 'Informational',
            'transactional' => 'Transactional',
            'navigational' => 'Navigational',
        ]],
        ['key' => 'related_entities', 'label' => 'Related Entities', 'type' => 'relationship'],
    ],
]);

Étape 3 : Exposer tout via l'API REST

L'API REST de WordPress est votre pont vers l'IA. Assurez-vous que les champs personnalisés sont exposés :

add_action('rest_api_init', function() {
    register_rest_field('knowledge_article', 'ai_metadata', [
        'get_callback' => function($post) {
            return [
                'summary' => get_field('summary', $post['id']),
                'concepts' => wp_get_post_terms($post['id'], 'concept', ['fields' => 'names']),
                'intent' => get_field('content_intent', $post['id']),
                'related' => get_field('related_entities', $post['id']),
                'structured_blocks' => parse_blocks(get_post_field('post_content', $post['id'])),
            ];
        },
    ]);
});

Si vous exécutez WordPress en tant que CMS sans tête avec un frontend Next.js ou Astro (ce que nous faisons beaucoup à Social Animal), cette API REST devient l'interface principale de votre IA.

Étape 4 : Ajouter les données structurées JSON-LD

Celui-ci est souvent négligé pour la préparation de l'IA, mais il compte. Google's AI Overviews et autres crawleurs d'IA consomment JSON-LD. Des outils comme Yoast SEO ou RankMath génèrent un schéma de base, mais pour une véritable préparation pour l'IA, vous voulez générer des données structurées détaillées :

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Make Your Content AI-Ready",
  "abstract": "How to structure existing CMS content for AI consumption",
  "about": [
    {"@type": "Thing", "name": "Content Management"},
    {"@type": "Thing", "name": "Artificial Intelligence"}
  ],
  "mentions": [
    {"@type": "SoftwareApplication", "name": "WordPress"},
    {"@type": "SoftwareApplication", "name": "Payload CMS"}
  ]
}

Payload CMS : Vous êtes plus proche que vous ne le pensez

Si vous êtes déjà sur Payload CMS, félicitations -- vous êtes probablement aux niveaux 2-3 sans travail supplémentaire. L'architecture basée sur les collections de Payload avec des champs typés est intrinsèquement structurée.

Pourquoi Payload est déjà adapté à l'IA

Payload stocke le contenu sous forme de documents JSON typés dans MongoDB ou Postgres. Chaque champ a un type défini. Les relations sont explicites. C'est exactement ce dont l'IA a besoin.

// Collection Payload déjà prête pour l'IA
const Articles: CollectionConfig = {
  slug: 'articles',
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'summary', type: 'textarea' },
    { name: 'body', type: 'richText' }, // Stocké en tant que Slate/Lexical JSON
    { name: 'topics', type: 'relationship', relationTo: 'topics', hasMany: true },
    { name: 'contentType', type: 'select', options: ['guide', 'tutorial', 'reference'] },
  ],
};

L'éditeur de texte enrichi de Payload (Lexical en v3.x) stocke le contenu en tant qu'AST JSON -- tout comme le Portable Text de Sanity. Vous avez déjà du contenu structuré.

Ajouter des champs spécifiques à l'IA à Payload

L'écart entre Payload et la préparation complète pour l'IA concerne principalement les métadonnées. Ajoutez ces champs à vos collections :

const aiFields: Field[] = [
  {
    name: 'aiMetadata',
    type: 'group',
    fields: [
      { name: 'embedding', type: 'json', admin: { hidden: true } },
      { name: 'extractedEntities', type: 'json', admin: { readOnly: true } },
      { name: 'semanticSummary', type: 'textarea', admin: { readOnly: true } },
      { name: 'contentHash', type: 'text', admin: { hidden: true } },
    ],
  },
];

Ensuite, utilisez les hooks de Payload pour générer automatiquement les plongements lors de la sauvegarde :

const generateEmbeddingHook: CollectionAfterChangeHook = async ({ doc, operation }) => {
  if (operation === 'create' || operation === 'update') {
    const textContent = extractTextFromLexical(doc.body);
    const embedding = await openai.embeddings.create({
      model: 'text-embedding-3-small',
      input: `${doc.title}\n${doc.summary}\n${textContent}`,
    });
    
    await payload.update({
      collection: 'articles',
      id: doc.id,
      data: {
        aiMetadata: {
          ...doc.aiMetadata,
          embedding: embedding.data[0].embedding,
          contentHash: hashContent(textContent),
        },
      },
    });
  }
};

C'est essentiellement ce que les fonctionnalités d'IA de Sanity font sous le capot. Vous le faites simplement vous-même. Pour les équipes construisant sur Payload avec Next.js, ce modèle s'intègre naturellement dans votre pipeline de déploiement existant.

Supabase en tant que couche de contenu prête pour l'IA

Supabase est intéressant car ce n'est pas un CMS -- c'est une plateforme de base de données. Mais de plus en plus, les équipes l'utilisent comme backend de contenu, notamment avec l'extension pgvector de Supabase pour les plongements.

L'avantage de pgvector

Supabase a le support pgvector depuis 2023, et il a beaucoup mûri. Cela signifie que vous pouvez stocker du contenu ET des plongements vectoriels dans la même base de données :

-- Activer l'extension
create extension if not exists vector;

-- Créer une table de contenu avec support des plongements
create table content (
  id uuid default gen_random_uuid() primary key,
  title text not null,
  body text not null,
  metadata jsonb default '{}',
  content_type text not null,
  embedding vector(1536), -- Dimension text-embedding-3-small d'OpenAI
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);

-- Créer un index pour la recherche de similarité
create index on content using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

Construire une API de contenu pour les agents d'IA

L'API REST auto-générée de Supabase et les Edge Functions vous donnent tout ce dont vous avez besoin :

// Fonction Supabase Edge pour la récupération de contenu IA
import { createClient } from '@supabase/supabase-js';

Deno.serve(async (req) => {
  const { query, limit = 5 } = await req.json();
  const supabase = createClient(Deno.env.get('SUPABASE_URL')!, Deno.env.get('SUPABASE_KEY')!);
  
  // Générer un plongement pour la requête
  const embeddingResponse = await fetch('https://api.openai.com/v1/embeddings', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'text-embedding-3-small',
      input: query,
    }),
  });
  
  const { data } = await embeddingResponse.json();
  const queryEmbedding = data[0].embedding;
  
  // Recherche sémantique utilisant pgvector
  const { data: results } = await supabase.rpc('match_content', {
    query_embedding: queryEmbedding,
    match_threshold: 0.7,
    match_count: limit,
  });
  
  return new Response(JSON.stringify(results), {
    headers: { 'Content-Type': 'application/json' },
  });
});

La fonction Postgres pour la correspondance de similarité :

create or replace function match_content(
  query_embedding vector(1536),
  match_threshold float,
  match_count int
) returns table (
  id uuid,
  title text,
  body text,
  metadata jsonb,
  similarity float
) language sql stable as $$
  select
    content.id,
    content.title,
    content.body,
    content.metadata,
    1 - (content.embedding <=> query_embedding) as similarity
  from content
  where 1 - (content.embedding <=> query_embedding) > match_threshold
  order by content.embedding <=> query_embedding
  limit match_count;
$$;

Cela vous donne un backend RAG (Retrieval-Augmented Generation) complètement fonctionnel sans aucune migration de CMS. Votre contenu vit dans Supabase, votre IA peut le interroger sémantiquement, et votre frontend Astro ou Next.js peut le consommer via la même API.

Les principes universels du contenu prêt pour l'IA

Quel que soit votre CMS, ces principes s'appliquent :

1. Séparer le contenu de la présentation

C'est la chose la plus importante que vous pouvez faire. Si votre contenu est mélangé avec du HTML, des classes CSS et des préoccupations de mise en page, l'IA ne peut pas l'analyser de manière fiable. Stockez le contenu en tant que données, rendez-le en tant que HTML à la couche de présentation.

2. Typer tout

Chaque champ doit avoir un type explicite. N'utilisez pas de champs de texte génériques pour les données structurées. Une date doit être stockée en tant que date. Une référence doit être une référence, pas une chaîne de caractères limace collée dans un champ de texte.

3. Rendre les relations explicites

Si l'article A fait référence au produit B, cela devrait être une relation typée -- pas une mention dans le texte du corps. Les outils d'IA doivent traverser votre graphe de contenu, et ils ne peuvent pas le faire avec des liens implicites.

4. Ajouter des métadonnées sémantiques

Allez au-delà des métadonnées SEO de base. Inclure :

  • Intention du contenu (informationnel, transactionnel, navigationnel)
  • Segment d'audience
  • Indicateurs de confiance/fraîcheur
  • Annotations d'entité
  • Classifications de sujet au-delà des catégories de base

5. Versioner et horodater tout

Les systèmes d'IA ont besoin de savoir à quel point le contenu est frais. Incluez created_at, updated_at, et idéalement un champ valid_until ou review_date. Le contenu obsolète dans un pipeline RAG conduit à des hallucinations.

Construire une couche d'abstraction pour l'IA

Voici le modèle auquel je reviens toujours : au lieu de migrer votre CMS, ajoutez une couche d'abstraction pour l'IA au-dessus.

[WordPress/Payload/Supabase] → [Content Sync] → [AI Layer (pgvector/Pinecone)] → [AI Consumers]

La couche d'IA :

  1. Synchronise le contenu de votre CMS via webhooks ou sondage
  2. Le normalise en une structure cohérente quelle que soit la source
  3. Génère les plongements et les stocke avec le contenu normalisé
  4. Expose une API optimisée pour l'IA pour RAG, l'appel d'outils et la recherche sémantique
// Pipeline de synchronisation de contenu simplifié
interface NormalizedContent {
  id: string;
  source: 'wordpress' | 'payload' | 'supabase';
  sourceId: string;
  title: string;
  body: string; // Texte brut, dépouillé de balisage
  structuredBody: object; // AST JSON si disponible
  metadata: {
    type: string;
    intent: string;
    topics: string[];
    entities: string[];
    createdAt: string;
    updatedAt: string;
  };
  embedding?: number[];
}

async function syncContent(source: ContentSource): Promise<void> {
  const rawContent = await source.fetchAll();
  
  for (const item of rawContent) {
    const normalized = source.normalize(item);
    const embedding = await generateEmbedding(
      `${normalized.title}\n${normalized.body}`
    );
    
    await aiLayer.upsert({
      ...normalized,
      embedding,
    });
  }
}

Cette approche a un énorme avantage : vos éditeurs continuent à utiliser le CMS qu'ils connaissent. Pas de recyclage, pas de migration, pas de temps d'arrêt. La couche d'IA vit aux côtés de votre pile existante.

Plongements vectoriels sans migration complète

Parlons des coûts et des outils pour 2025, car cela compte pour les décisions du monde réel :

Fournisseur d'intégration Modèle Coût par 1M tokens Dimensions Notes
OpenAI text-embedding-3-small $0.02 1536 Meilleur rapport coût/qualité
OpenAI text-embedding-3-large $0.13 3072 Exactitude plus élevée
Cohere embed-v4 $0.10 1024 Bon support multilingue
Voyage AI voyage-3 $0.06 1024 Fort pour le contenu de code
Local (Ollama) nomic-embed-text Gratuit 768 Option axée sur la confidentialité

Pour un site de contenu typique avec 5 000 articles de 1 500 mots en moyenne, vous envisagez environ 7,5 M tokens. Avec le petit modèle d'OpenAI, cela représente 0,15 $ pour intégrer toute votre bibliothèque de contenu. Même la réintégration hebdomadaire est négligeable.

Options de stockage vectoriel

Solution Niveau gratuit Tarification (2025) Meilleur pour
Supabase pgvector 500 MB de base de données $25/mois pour 8 GB Équipes déjà sur Supabase
Pinecone 5 M de vecteurs $70/mois démarrage Production RAG à grande échelle
Qdrant Cloud Cluster 1 GB $25/mois Besoins de filtrage avancé
Weaviate Cloud 50 k objets $25/mois Contenu multi-modal
Turbopuffer 1 M de vecteurs Payer par requête Projets sensibles aux coûts

Si vous exécutez déjà Supabase, pgvector est le choix évident. Aucun service supplémentaire, aucune facturation supplémentaire, aucun point de défaillance supplémentaire.

Modèles d'architecture du monde réel

Permettez-moi de partager deux architectures que j'ai réellement construites :

Modèle 1 : WordPress + Supabase Couche d'IA

Pour une entreprise de médias avec 50 000+ articles WordPress :

  1. Webhook WordPress se déclenche lors de la sauvegarde/mise à jour de la publication
  2. Une fonction Supabase Edge reçoit le webhook
  3. Le contenu est récupéré via l'API WP REST, normalisé et intégré
  4. Stocké dans Supabase avec pgvector
  5. Le chatbot IA sur le frontend Next.js interroge Supabase pour la recherche sémantique
  6. Les résultats sont transmis à GPT-4o comme contexte pour la génération de réponses

Coût d'infrastructure supplémentaire total : ~$25/mois pour le niveau professionnel Supabase.

Modèle 2 : Payload CMS avec IA intégrée

Pour un site de documentation SaaS sur Payload v3 :

  1. Les hooks Payload génèrent des plongements à chaque sauvegarde de document
  2. Les plongements stockés dans une colonne vector dans la même base de données Postgres que Payload utilise
  3. Point de terminaison Payload personnalisé pour la recherche sémantique
  4. Assistant de documentation IA alimenté par la même base de données
  5. Aucun magasin de vecteurs externes nécessaire

Coût d'infrastructure supplémentaire total : 0 $ au-delà des appels API OpenAI (quelques centimes par mois).

Les deux modèles ont pris environ 2 à 3 semaines à implémenter, comparé aux 3 à 6 mois qu'une migration complète de CMS prendrait. Si vous envisagez ce type d'architecture, nous avons des niveaux tarifaires qui couvrent exactement ces types de projets.

FAQ

Dois-je vraiment restructurer mon contenu pour l'IA, ou c'est juste du battage médiatique ?

Ce n'est pas du battage médiatique, mais l'urgence dépend de votre cas d'usage. Si vous construisez des fonctionnalités d'IA (chatbots, recherche sémantique, personnalisation), le contenu structuré est essentiel. Si vous optimisez pour la recherche basée sur l'IA comme les AI Overviews de Google ou la navigation ChatGPT, les données structurées et les hiérarchies de contenu propres améliorent considérablement votre visibilité. Une étude 2025 d'Authoritas a constaté que les pages avec balisage de schéma étaient 40% plus susceptibles d'apparaître dans les réponses générées par l'IA.

Quel est le minimum que je devrais faire pour préparer le contenu WordPress pour l'IA ?

Trois choses : (1) Utilisez les blocs Gutenberg régulièrement au lieu de coller du HTML, (2) ajoutez des données structurées JSON-LD à chaque page, et (3) exposez les champs personnalisés via l'API REST. Cela vous fait passer du niveau 0-1 au niveau 2-3 en quelques semaines de travail ciblé. Vous n'avez pas besoin de restructurer votre site entier du jour au lendemain.

Payload CMS peut-il remplacer Sanity pour le contenu alimenté par l'IA ?

Pour la plupart des cas d'usage, oui. Payload v3 avec le texte enrichi Lexical stocke le contenu en tant que JSON structuré, possède des champs et des relations typés, et prend en charge Postgres avec pgvector. La principale chose que Sanity offre que Payload n'a pas en natif est le Content Lake géré avec les fonctionnalités d'IA intégrées. Mais si vous êtes prêt à câbler votre propre pipeline d'intégration (ce qui prend environ une journée), Payload vous donne des capacités équivalentes.

Combien coûte l'ajout de plongements vectoriels à un CMS existant ?

Étonnamment peu. Pour un site avec 10 000 articles, la génération de plongement initial avec text-embedding-3-small d'OpenAI coûte environ 0,30 $. Les coûts continus de réintégration du contenu mis à jour sont généralement inférieurs à $5/mois. Le stockage de vecteur est le coût le plus élevé -- attendez-vous à $0-70/mois selon votre fournisseur et votre échelle. Le niveau gratuit de Supabase peut gérer de nombreux petits et moyens sites.

Dois-je utiliser une base de données vectorielle séparée ou stocker les plongements dans ma base de données existante ?

Si vous êtes sur Postgres (ce que Payload v3 et Supabase utilisent tous les deux), stockez les plongements dans la même base de données avec pgvector. Un service de moins à gérer, une synchronisation de moins à casser. Les bases de données vectorielles dédiées comme Pinecone ont du sens lorsque vous avez des millions de documents ou que vous avez besoin de temps de requête inférieur à la milliseconde. Pour la plupart des sites de contenu, pgvector est plus que suffisant -- les temps de requête typiques sont 5-20 ms pour les collections de moins de 1 M vecteurs.

Comment maintenir les plongements d'IA en synchronisation avec les modifications de contenu ?

Les webhooks sont votre meilleur ami. Chaque CMS moderne les prend en charge. Lorsque le contenu est créé ou mis à jour, déclenchez un webhook qui déclenche une réintégration. Stockez un hachage de contenu avec le plongement afin que vous puissiez ignorer le contenu inchangé. Pour WordPress, utilisez l'action save_post. Pour Payload, utilisez les crochets afterChange. Pour Supabase, utilisez les déclencheurs de base de données ou les abonnements Realtime.

Qu'en est-il du contenu en plusieurs langues -- cette approche fonctionne-t-elle toujours ?

Oui, mais choisissez votre modèle d'intégration avec soin. Les modèles text-embedding-3 d'OpenAI gèrent bien le contenu multilingue. L'embed-v4 de Cohere est spécifiquement optimisé pour la récupération multilingue. La couche de normalisation doit stocker le code de langue en tant que métadonnées afin que vos consommateurs d'IA puissent filtrer correctement. Une note importante : intégrez séparément chaque version de langue plutôt que de concaténer les traductions.

La migration vers un CMS sans tête est-elle un prérequis pour du contenu prêt pour l'IA ?

Pas un prérequis, mais cela aide énormément. L'architecture du CMS sans tête sépare naturellement le contenu de la présentation, ce qui est le fondement de la préparation pour l'IA. Si vous exécutez toujours un thème WordPress monolithique avec un contenu intégré dans les fichiers de modèle, passer au mode sans tête (WordPress comme backend avec un frontend Next.js ou Astro) améliore simultanément votre préparation pour l'IA et les performances de votre frontend. Cela vaut souvent l'investissement même avant de considérer les cas d'usage de l'IA. Si vous voulez explorer cela, contactez-nous -- c'est littéralement ce que nous faisons tous les jours.