Voici ce qui se passe quand les entreprises sautent l’étape de la définition – et comment l’éviter.

Quand « IA » veut tout dire, ça ne veut rien dire

Le terme « IA » recouvre aujourd’hui un éventail énorme de technologies : l’automatisation basée sur des règles, les moteurs de recommandation, les modèles d’apprentissage automatique, les grands modèles linguistiques comme GPT-5.5, et les agents IA entièrement autonomes. Ce sont des choses fondamentalement différentes, avec des coûts, des capacités et des modes de défaillance bien distincts. Pourtant, on les appelle toutes « IA » en réunion de direction et lors des discussions budgétaires.

C’est un peu comme appeler « véhicule » tout ce qui a un moteur. Techniquement correct, mais pas très utile quand tu dois décider si tu as besoin d’un chariot élévateur ou d’une voiture de fonction.

Dans la pratique, ce flou pose trois problèmes concrets à quiconque essaie de prendre des décisions :

• Pour les clients, ça rend l’évaluation des fournisseurs presque impossible – tu ne peux pas comparer des solutions si tu ne sais pas quel problème tu cherches à résoudre.
• Pour les équipes internes, ça crée de la confusion sur ce qui est attendu et sur la façon dont le succès sera mesuré.
• Pour la conformité, ça rend l’évaluation des risques, des responsabilités et de l’adéquation réglementaire presque impossible.

En Suisse notamment, où les exigences de conformité sont élevées et où les PME opèrent sous un contrôle réglementaire strict, « on met en place l’IA » n’est pas une réponse suffisante pour les auditeurs, les délégués à la protection des données ou les responsables des achats. Le flou dans les définitions n’est pas une question théorique – il crée un vrai risque juridique et financier.

Quand un nouveau client dit « on a besoin d’IA », notre équipe chez what. pose toujours la même série de questions avant toute chose :

• Quelle tâche ou décision spécifique cherches-tu à améliorer ou à automatiser ?
• Où exactement le processus actuel se bloque-t-il ou ralentit-il ?
• Est-ce que ça nécessite du jugement et de l’adaptabilité, ou s’agit-il d’une tâche prévisible basée sur des règles ?
• Comment vas-tu mesurer si ça fonctionne ?
• Qui est responsable du résultat si ça tourne mal ?

Ce ne sont pas des questions pour te barrer la route. C’est le fondement de tout projet qui aboutit réellement.

Pourquoi des objectifs flous font échouer les projets avant même qu’ils démarrent

Les entreprises adoptent souvent l’IA parce que ça semble urgent – les concurrents « se lancent dans l’IA », la direction pose des questions, et personne ne veut être à la traîne. C’est compréhensible. Mais adopter l’IA parce que c’est dans l’air du temps, plutôt que parce qu’on a identifié un problème précis qu’elle permet de résoudre, c’est ainsi que les budgets disparaissent sans rien produire de concret.

Sans une définition claire de ce que l’IA est censée faire, trois choses deviennent véritablement impossibles :

Ça rejoint directement un sujet dont nous avons déjà parlé : le principe « garbage in, garbage out » (si on entre des données erronées, on obtient des résultats erronés). Comme nous l’avons exploré dans « Avant de te lancer dans l’IA, commence par améliorer tes processus », une IA construite sur des processus défaillants ou mal définis ne règle pas ces problèmes – elle ne fait qu’accélérer la confusion.

À quoi ressemble une définition utile de l’IA

Plutôt que de débattre de ce qu’« est » l’IA dans l’abstrait, la question la plus productive est : qu’est-ce qu’elle doit faire pour ton entreprise, et a-t-elle vraiment besoin de l’IA pour y parvenir ?

Avant de lancer un projet d’IA, passe en revue cette liste de contrôle :

• Quelle tâche spécifique ce système doit-il accomplir ? (Une seule tâche, définie avec précision.)
• Doit-il apprendre, s’adapter ou gérer des entrées ambiguës – ou une automatisation plus simple basée sur des règles ferait-elle tout aussi bien l’affaire ?
• Quel niveau de supervision humaine est nécessaire, et à quels moments ?
• Comment le succès sera-t-il mesuré, et dans quel délai ?
• Est-ce vraiment différent de l’automatisation standard ?

Cette dernière question est la plus importante. Si la réponse honnête est « pas vraiment » – ce n’est pas un échec. C’est le signe qu’il faut utiliser l’outil plus simple, moins cher et plus fiable.

C’est particulièrement important dans le contexte suisse. Les coûts de main-d’œuvre y sont parmi les plus élevés au monde. Tout projet d’automatisation IA mal défini coûte deux fois plus cher : une fois en dépenses directes, et une fois en heures de travail perdues à cause d’un outil qui ne fonctionne pas correctement. Être précis dès le départ, ce n’est pas de l’ingénierie excessive – c’est de la discipline financière élémentaire.

Il faut aussi noter que beaucoup de problèmes présentés comme des problèmes d’IA sont en fait des problèmes d’intégration. Quand un client nous dit que son équipe passe des heures à réconcilier manuellement des données entre son CRM, son ERP et son système comptable, il suppose souvent qu’il a besoin de l’IA pour régler ça. En général, ce n’est pas le cas. Il a besoin que ses systèmes communiquent entre eux. Notre travail d’intégration d’outils résout la plupart de ces situations sans aucun modèle d’IA – et le fait plus vite et de manière plus fiable.

Ce qu’en dit notre expert IA

Ce qu’en dit notre expert IA

La plupart des clients n’ont pas un problème d’IA – ils ont un problème de clarté. Une fois qu’on a défini la tâche réelle, la bonne solution apparaît généralement d’elle-même, et elle est souvent plus simple qu’ils ne le pensaient.

Sergei Gordeichuk

Responsable technologique chez what.

Définir d’abord, construire ensuite

Les entreprises qui obtiennent de vrais résultats avec l’IA ne sont pas forcément celles qui avancent le plus vite. Ce sont celles qui avaient le plus clairement cerné le problème à résoudre avant de s’engager sur une solution.

Un brief précis – qui définit la tâche, les critères de réussite, les besoins en données et les attentes en matière de gouvernance – vaut mieux que n’importe quel outil. L’automatisation IA devient vraiment puissante une fois que ces bases sont en place. Pas du battage médiatique, pas une démo qui finit au placard au bout d’un mois. Un vrai levier, appliqué à un problème bien compris.

Si tu ne sais pas encore si ce à quoi tu es confronté est un problème d’IA, d’automatisation ou d’intégration, c’est exactement la bonne question à te poser avant de dépenser quoi que ce soit. Contacte notre agence d’automatisation IA – on t’aidera à trouver la réponse honnête.

The post L’IA sans définition : pourquoi ça se retourne contre toi appeared first on what. AG.

Demande à l’IA quelle est la politique tarifaire actuelle de ton entreprise et elle pourrait citer une version vieille de deux ans. Demande-lui une étude de cas avec de vrais chiffres de retour sur investissement et elle pourrait en générer une qui semble plausible, mais qui ne s’est jamais réellement produite. C’est ce qu’on appelle une hallucination – ou une dérive quand le schéma se répète.

Pourquoi ça arrive ? Le modèle a été entraîné sur des données qui existaient avant ta question. Il n’a pas accès à ce que tu as rédigé en interne, mis à jour récemment ou stocké dans tes systèmes – et même si certains modèles peuvent interroger le Web pour combler les lacunes, ce n’est ni fiable ni efficace pour les connaissances propres à ton entreprise. Il comble donc les lacunes avec la réponse statistiquement la plus probable, qui n’est pas toujours la bonne.

Le RAG – abréviation de Retrieval-Augmented Generation – est la solution la plus pratique à ce problème. Au lieu de se fier à la mémoire du modèle, le RAG le connecte à ta vraie base de connaissances en temps réel. Politiques d’entreprise, documents commerciaux, manuels internes, FAQ – quand quelqu’un pose une question, le système trouve d’abord les passages pertinents dans ton contenu, les ajoute comme contexte, puis génère une réponse sur cette base.

C’est vraiment puissant. Ta documentation interne peut devenir une sorte d’oracle opérationnel, capable de répondre en langage clair. Mais ce n’est pas de la magie, et ce n’est pas l’outil adapté à toutes les situations.

À la fin de cet article, tu sauras ce que fait réellement le RAG, comment préparer ton contenu pour l’utiliser, et quand c’est le bon choix – et quand tu as besoin de quelque chose de plus structuré.

Comment fonctionne le RAG (sans jargon)

Le RAG s’intercale de manière invisible entre ta question et la réponse de l’IA. Le modèle ne répond pas uniquement depuis sa mémoire – il récupère d’abord les informations pertinentes dans ta base de connaissances et s’en sert comme base pour sa réponse.

Voici le processus, en quelques mots :

1. Préparation du contenu : tu charges tes documents (politiques, FAQ, procédures) dans le système dans un format structuré et lisible.
2. Indexation : le système traite ce contenu avec deux approches complémentaires – la recherche classique par mots-clés et la recherche sémantique (on y revient plus bas).
3. Extraction : quand une question arrive, l’index extrait les passages les plus pertinents.
4. Génération : l’IA produit une réponse en s’appuyant sur ces passages extraits, combinés à ses connaissances générales.

Le résultat, c’est une réponse ancrée dans ton contenu réel, et non générée de toutes pièces.

Pourquoi la recherche hybride est importante

La recherche par mots-clés fonctionne bien quand quelqu’un utilise exactement le terme qui apparaît dans un document. La recherche sémantique va plus loin : elle comprend le sens, pas seulement les mots.

Par exemple : « comment augmenter la marge de l’entreprise » et « réduire les frais d’exploitation » renvoient au même concept, mais ne partagent presque aucun mot-clé. La recherche sémantique trouve du contenu pertinent même quand la formulation est différente. En pratique, les systèmes RAG bien conçus utilisent les deux approches ensemble. Les mots-clés capturent les références précises, les codes produit et les noms propres. La recherche sémantique gère tout ce qui relève de l’intention plutôt que de la formulation exacte.

RAG vs. réglage fin

Ces deux concepts sont souvent confondus. Le RAG ne modifie pas le modèle lui-même – il utilise un LLM prêt à l’emploi (comme Claude ou GPT) et lui transmet les bons extraits de ta base de connaissances pour chaque question. Mets à jour la base de connaissances, réindexe-la, et les réponses restent à jour.

Le fine-tuning, c’est différent. Il ajuste de manière permanente le comportement ou le langage du modèle. C’est utile quand tu as besoin d’un style cohérent ou d’un comportement spécifique à un domaine – pas quand tu as surtout besoin de réponses précises et actuelles issues de documents.

Une chose importante à garder en tête : la qualité du RAG dépend de la qualité de son extraction. Un mauvais contexte en entrée donne une réponse assurée mais fausse en sortie. Plus de contenu extrait signifie aussi plus de tokens traités, ce qui augmente les coûts. Cet équilibre se conçoit délibérément – ce n’est pas une question de « plus de documents = meilleures réponses ».

Chez what., on ne construit pas toujours le RAG de zéro. On choisit l’approche qui correspond au besoin réel – RAG sur mesure, solutions de recherche gérées, ou une combinaison des deux – pour que tu investisses là où ça rapporte vraiment.

À lire aussi : Pourquoi as-tu besoin de l’IA pour automatiser tes processus ?

Préparer ta base de connaissances IA : pourquoi le format compte plus que tu ne le penses

Le RAG extrait ce que tu as écrit. Si tes documents sont désordonnés, fragmentés ou mal structurés, le système ne comprendra pas ton activité comme par magie – il trouvera des fragments faibles et le modèle comblera les lacunes avec assurance. C’est là que les hallucinations refont surface.

La qualité de l’extraction dépend presque autant de ton contenu que de l’algorithme qui le sous-tend.

Markdown vs. PDF

Les PDF sont parfaits pour la lecture et le partage. Pour le RAG, ils sont souvent un casse-tête. Mises en page complexes, tableaux cassés, pages numérisées – tout ça nécessite un OCR ou une étape d’analyse avant de pouvoir être indexé. Ça ajoute des coûts, du temps de traitement et un risque réel de voir du texte déformé se retrouver dans ta base de connaissances. Des outils comme LlamaIndex sont largement utilisés pour gérer ça quand le PDF est inévitable, mais c’est toujours plus d’efforts qu’un texte structuré propre.

Le Markdown fonctionne mieux parce que la structure est explicite : les titres, les sections et les listes indiquent au système d’indexation exactement où un sujet se termine et où un autre commence. Pour un modèle d’IA qui tente de récupérer le bon fragment, cette clarté fait une vraie différence.

Le Markdown est aussi indépendant du format. Il se convertit proprement en HTML, Word, PDF et la plupart des exports CMS, ce qui évite que ton pipeline RAG ne soit lié à un fournisseur ou un outil spécifique. Et c’est la norme dans la documentation logicielle depuis des années, précisément parce qu’il s’agit de texte brut, facile à versionner et simple à maintenir.

La règle pratique : garde les PDF pour l’archivage et la distribution. Utilise le Markdown (ou un texte structuré équivalent) comme format de travail pour tout ce qui va dans le RAG. Si tu n’as que des PDF numérisés, prévois un budget pour l’extraction – c’est faisable, mais ça coûte plus cher et ça augmente le risque d’erreurs.

Comment structurer tes documents pour la recherche

Quelques habitudes simples font une vraie différence dans les performances du RAG :

• Un sujet par section. Utilise des titres clairs. Évite les fichiers volumineux qui couvrent tout – privilégie les documents thématiques ou les sections bien séparées pour que la recherche renvoie des blocs cohérents plutôt qu’un demi-chapitre mélangé à du contenu sans rapport.
  
• Des titres descriptifs et précis. « Introduction » ou « Annexe » n’aident pas la recherche. « Politique de télétravail – Suisse » ou « Gestion des objections sur les prix – clients enterprise », oui. Le titre est souvent ce qui est repéré en premier.
  
• Place les codes et les références dès le début. Si tu utilises des codes de procédure internes, des noms de modules ou des références produit, inclus-les dans le titre ou la première ligne. Ça permet à la recherche par mots-clés de trouver immédiatement ce qu’il faut.
  
• Utilise des listes numérotées pour les processus. Les procédures étape par étape sont plus faciles à retrouver et à citer que des paragraphes denses. S’il y a une séquence, présente-la comme une séquence.
  
• Élimine le bruit. En-têtes et pieds de page répétés, mentions légales sur chaque page, versions en double d’un même document – tout ça pollue ton index. Un contenu épuré se retrouve plus facilement.

Une remarque sur le découpage

Les longs documents sont divisés en morceaux plus petits pour l’indexation. Les morceaux trop grands génèrent trop de bruit ; ceux trop petits perdent le fil du sens. Le découpage au niveau des titres Markdown permet naturellement de regrouper les contenus liés et réduit le risque de couper un concept en deux.

Les bons pipelines d’indexation utilisent aussi le chevauchement – quelques lignes des sections adjacentes sont incluses dans chaque fragment pour que le modèle ne perde pas le contexte aux limites. Si un document est court et toujours pertinent dans un flux donné, l’inclure en entier est parfois plus efficace que de se fier uniquement aux fragments extraits.

La vraie question à se poser avant d’acheter un modèle ou une plateforme plus coûteux : ta base de connaissances est-elle réellement consultable ? Un RAG bien conçu sur du contenu propre surpassera systématiquement une configuration médiocre sur des PDF chaotiques, pour un coût d’API identique.

Tout ne trouve pas sa place dans le RAG de la même manière

Ça vaut la peine de réfléchir à ce qui va où. Trois catégories sont utiles :

Une erreur courante consiste à intégrer des procédures étape par étape critiques dans le RAG en espérant que le modèle les suivra dans l’ordre. Ce ne sera pas le cas de manière fiable. La recherche trouve des fragments pertinents – elle ne remplace pas un moteur de workflow avec un enchaînement imposé.

À lire aussi : Avant de te lancer dans l’IA, commence par améliorer tes processus.

Quand le RAG suffit – et quand tu as besoin de plus

C’est la question qui évite aux équipes de surdimensionner ou de sous-dimensionner leurs solutions.

Le RAG associé à un LLM est la bonne configuration quand quelqu’un pose une question et a besoin d’une réponse ancrée. Ce n’est pas la bonne configuration quand l’interaction nécessite un processus avec des étapes obligatoires, un état suivi d’une session à l’autre, ou des décisions séquentielles qui ne peuvent pas être ignorées.

Deux modèles mentaux :

Règle rapide : une question, une réponse, pas de séquence obligatoire entre les sessions – commence par RAG et un LLM. Même utilisateur, plusieurs échanges, étapes qui ne peuvent pas être ignorées – ajoute l’orchestration. Le RAG sert alors de bibliothèque de soutien, pas de pilier du processus.

Trois cas où RAG + LLM est la bonne solution

• FAQ interne ou politique RH. « Quelle est notre politique de télétravail pour les employés basés en Suisse ? » – Un corpus bien indexé, une réponse ancrée dans le document de politique réel, aucun parcours en plusieurs étapes requis. On trouve, on explique, c’est fait.
  
• Aide à la vente. « Avons-nous une étude de cas logistique avec un retour sur investissement ? » – Une bibliothèque de documents commerciaux que les utilisateurs explorent selon leur intention, pas un script fixe. Le RAG gère ça naturellement.
  
• Assistance produit (L1). « Comment réinitialiser la connexion sur l’appareil X ? » – Une question, une réponse, directement liée au manuel. Si la recherche échoue, corrige le document, pas toute l’architecture.

Trois cas où tu as besoin d’une architecture plus solide

• Coaching ou conseil numérique avec un guide pratique. Des missions de plusieurs semaines où tu suis des objectifs, passes en revue les options et conclus avec un plan. Les règles relatives à l’étape et à la session en cours doivent exister en dehors du modèle – dans une base de données ou une machine à états. Le RAG fournit des cadres et des exemples quand l’étape le demande. Sans orchestration, l’IA saute des phases ou oublie ce qui a été convenu deux sessions plus tôt.
  
• Intégration d’un employé ou d’un partenaire. Semaine 1 : documents. Semaine 2 : formation. Semaine 3 : évaluation des compétences. Cet ordre peut être contractuel ou dicté par la conformité. Trouver le bon PDF ne suffit pas – tu ne peux pas ouvrir le module 3 tant que le module 2 n’est pas terminé. Le RAG fournit le contenu ; une machine à états guide le parcours.
  
• Découverte commerciale guidée. Qualification, puis analyse des besoins, puis proposition – avec des questions obligatoires à chaque étape. Le RAG récupère les tarifs, les argumentaires et les réponses aux objections. Un orchestrateur impose la séquence : « pas de discussion sur les tarifs avant que les besoins ne soient déclarés ». Sans ça, l’IA propose des devis trop tôt ou invente un cadre qui n’est pas le tien.

Corrige ton contenu avant de blâmer le modèle

Quand le RAG ne donne pas les résultats escomptés, la tentation est de mettre à niveau le modèle ou de passer à une plateforme plus coûteuse. En général, c’est la mauvaise décision.

La plupart des problèmes de recherche sont dus à la qualité du contenu, pas aux capacités du modèle. Des documents trop longs, mal intitulés ou dupliqués entre différentes versions vont semer la confusion même dans le meilleur système de recherche. La solution est d’ordre éditorial, pas architectural.

Avant d’investir dans l’infrastructure, vérifie trois choses :

1. Le contenu est-il prêt ? Structuré, géré, à jour – pas un mélange de PDF éparpillés et de six versions du même document de politique.
2. S’agit-il d’un problème de recherche-réponse ou de suivi de parcours ? Les FAQ et les politiques nécessitent généralement RAG + LLM. Les guides pratiques et les processus d’intégration en plusieurs étapes nécessitent aussi une orchestration.
3. La réussite est-elle clairement définie ? « Des réponses utiles liées à des sources » est un critère de réussite. « Ça a l’air intelligent » ne l’est pas.

Un moyen rapide de trouver le vrai goulot d’étranglement : choisis un domaine, sélectionne 20 à 30 documents, note 10 questions réelles que ton équipe pose vraiment. Lance le test. En quelques jours, tu sauras si le problème vient de la recherche, de la qualité du contenu ou de l’architecture – et tu n’auras presque rien dépensé pour le découvrir.

Tu veux des workflows d’IA fiables de bout en bout, et pas seulement au niveau de la recherche ? Nos services d’intégration d’outils aident à connecter les systèmes dont dépend ton pipeline RAG – pour que les données s’intègrent proprement dans ta base de connaissances et restent à jour sans effort manuel.

Prêt à construire une base de connaissances qui fonctionne vraiment ?

La bonne question n’est pas « quelle plateforme d’IA dois-je acheter ? », mais « est-ce que j’ai une base de connaissances qui vaut la peine d’être exploitée – et un processus qui sait quand s’appuyer sur le RAG et quand ne pas le faire ? »

C’est exactement le genre de question sur laquelle on aide les équipes à se pencher. En tant qu’agence d’automatisation IA, what. collabore avec les entreprises pour concevoir des configurations RAG adaptées au cas d’usage réel – ni plus complexes que nécessaire, ni sous-dimensionnées pour la tâche. Qu’il s’agisse d’une configuration légère exclusivement RAG ou d’un workflow IA entièrement orchestré, on t’aide à déterminer le bon niveau de complexité avant de construire quoi que ce soit.

Contacte-nous pour un entretien ciblé. Pas de discours commercial – juste une analyse honnête pour déterminer si le RAG est la solution adaptée et ce qu’il faudrait pour qu’il fonctionne bien.

The post RAG expliqué : comment intégrer ta base de connaissances à l’IA appeared first on what. AG.

Comprendre cette évolution est essentiel pour quiconque développe ou évolue dans l’espace Web3 aujourd’hui.

Des chaînes monolithiques à l’infrastructure modulaire

Les premières blockchains étaient conçues pour tout faire en un seul endroit. Un seul réseau gérait l’exécution des transactions, parvenait à un consensus, garantissait la disponibilité des données et assurait la finalité des règlements. Bitcoin et les premières versions d’Ethereum en sont les exemples les plus évidents : des systèmes unifiés où chaque nœud participe à toutes les fonctions.

Le problème de cette approche, c’est la scalabilité. Quand une seule chaîne doit tout faire, elle atteint rapidement ses limites. Une demande plus forte entraîne des frais plus élevés, des transactions plus lentes et une pression pour faire des compromis entre décentralisation et performance.

L’approche modulaire sépare ces responsabilités. L’exécution, le règlement, le consensus et la disponibilité des données deviennent chacun des couches distinctes, optimisables indépendamment les unes des autres. Un rollup, par exemple, gère l’exécution hors de la chaîne principale et publie les données de transaction sur une couche de disponibilité des données séparée comme Celestia ou EigenDA, tout en effectuant le règlement sur Ethereum. Chaque composant fait une seule chose, et la fait bien – plutôt qu’un seul système qui tente de tout faire de manière correcte.

Ce changement d’architecture reflète ce qui s’est passé plus largement dans le domaine du génie logiciel : le passage des applications monolithiques aux microservices. La logique est la même : la spécialisation permet l’évolutivité.

Pour les développeurs et innovateurs de l’espace crypto, cette base modulaire a ouvert de nouvelles perspectives. Les développeurs peuvent désormais lancer des chaînes spécifiques à une application sans construire une infrastructure de validation à partir de zéro, se connecter à des couches de sécurité partagées et choisir des solutions de disponibilité des données adaptées à leurs besoins et à leur budget.

La pile s’étend au-delà de la scalabilité

C’est là que ça devient vraiment intéressant. La pile blockchain modulaire a démarré comme une réponse à un problème de scalabilité. Mais elle devient de plus en plus autre chose : une infrastructure permettant aux agents IA autonomes de communiquer, d’effectuer des transactions et de se coordonner.

Ça peut sembler tiré par les cheveux, mais la logique s’impose naturellement. Les agents IA – des systèmes logiciels capables d’agir, de prendre des décisions et d’interagir avec des services externes au nom d’un utilisateur – sont de plus en plus performants et autonomes. À mesure qu’ils commencent à participer à l’activité économique réelle, ils ont besoin d’une infrastructure fiable pour les soutenir. Ils doivent prouver qui les a autorisés, effectuer des paiements, vérifier la fiabilité d’autres agents et laisser des traces auditables de leurs actions.

Les propriétés fondamentales de la blockchain – registres transparents, règles programmables, identité portable et journaux inviolables – correspondent presque parfaitement à ce dont l’IA agentique a besoin. La pile ne remplace pas l’IA ; elle fournit les rails de confiance et de responsabilité qui rendent l’activité des agents autonomes sûre et vérifiable.

La convergence entre l’IA agentique et l’infrastructure décentralisée n’est pas un scénario futur – elle façonne déjà notre façon de penser l’architecture Web3 aujourd’hui. Les projets qui définiront la prochaine phase ne se contentent pas de s’appuyer sur la blockchain ; ils construisent la couche de coordination qui permet aux systèmes autonomes d’agir avec confiance, responsabilité et dans un but économique.

Liwaa Chehayeb

Responsable Web3 chez what.

À noter également : l’ère de la tokenisation en cours témoigne d’une évolution parallèle – la blockchain passe d’une infrastructure purement spéculative à des systèmes qui soutiennent une réelle valeur économique. L’IA agentique accélère cette même trajectoire.

Les protocoles qui façonnent la pile Web3 agentique

Plusieurs protocoles et normes émergents étendent la pile modulaire spécifiquement pour soutenir l’activité des agents IA. Ensemble, ils forment ce qu’on pourrait raisonnablement appeler une infrastructure de commerce agentique.

Communication entre agents : A2A

A2A (protocole Agent-to-Agent) traite de la manière dont les agents IA communiquent entre eux. L’avenir de l’IA agentique ne repose pas sur un agent omniscient qui fait tout. Il s’agit d’un réseau d’agents spécialisés, chacun gérant un domaine particulier.

Un agent s’occupe de la recherche, un autre des paiements, un autre encore des contrôles de conformité. A2A fournit le langage commun que ces agents utilisent pour se coordonner et se déléguer des tâches.

Accès aux outils : MCP

Le MCP (Model Context Protocol) gère l’accès aux outils. Il permet aux agents de se connecter à des systèmes externes : bases de données, API, explorateurs de blockchain, workflows métier, services de paiement.

Sans MCP, un agent est pratiquement isolé. Avec lui, un agent peut réellement interagir avec le monde numérique : vérifier une transaction on-chain, récupérer un document, appeler une API de tarification ou déclencher un processus métier.

Autorisation de paiement : AP2

AP2 (Agent Payments Protocol) se concentre spécifiquement sur l’autorisation. Quand un agent IA effectue un paiement au nom d’un utilisateur, une question cruciale se pose : est-ce que ça a vraiment été autorisé ? AP2 est conçu pour y répondre.

Il s’agit moins des mécanismes de transfert d’argent que du consentement, des périmètres d’autorisation et de la responsabilité. Considère-le comme la couche d’autorisation qui se situe au-dessus du paiement proprement dit.

Exécution du paiement : x402

x402 gère l’exécution du paiement. Il reprend l’ancien code d’état HTTP 402 « Payment Required » et le transforme en une norme opérationnelle pour les micropaiements natifs d’Internet.

Un agent peut payer une requête de données premium, un appel API, ou même rémunérer un autre agent pour avoir accompli une sous-tâche – le tout automatiquement, sans intervention humaine à chaque étape. AP2 prouve que l’agent était autorisé ; x402 gère le flux de transaction proprement dit.

Identité et réputation de l’agent : ERC-8004

ERC-8004 s’occupe de l’identité et de la réputation des agents. À mesure que les agents interagissent de plus en plus avec d’autres agents en dehors de leur propre plateforme ou organisation, ils ont besoin d’un moyen d’évaluer leur fiabilité.

Qui a créé cet agent ? A-t-il déjà accompli des tâches avec succès ? Ses déclarations peuvent-elles être vérifiées ? L’ERC-8004 vise à créer une couche de réputation ouverte pour les interactions entre agents – en aidant essentiellement les agents à décider à qui ils peuvent faire confiance et à qui ils peuvent payer.

Smart wallets, limites de dépenses et autonomie restreinte

L’une des questions de conception les plus importantes en IA agentique est simple : de quelle autonomie financière un agent devrait-il disposer ?

La réponse : une autonomie restreinte. Pas un accès illimité à un portefeuille, mais un accès programmable et soumis à des règles. Les portefeuilles intelligents (smart wallets) et l’abstraction de compte rendent ça possible. Un utilisateur ou une entreprise peut configurer un agent pour qu’il ne dépense qu’un certain montant par jour, n’effectue des transactions qu’avec des contreparties approuvées, demande une validation humaine au-delà d’un certain seuil, ou évite complètement certains types de transactions. Chaque action est enregistrée pour être vérifiée.

C’est important parce que l’objectif n’est pas une autonomie maximale – c’est une autonomie utile dans un cadre clairement défini. Un agent de voyage IA qui réserve le vol le moins cher dans les limites de ton budget, c’est utile. Un agent IA avec un accès illimité à tes fonds, c’est un risque.

La coordination inter-chaînes et l’opportunité en matière d’expérience utilisateur

Les agents IA ne se soucieront pas de la blockchain sur laquelle un service fonctionne. Ce qui les intéressera, c’est de savoir si la tâche peut être accomplie rapidement, à moindre coût et en toute sécurité. L’interopérabilité devient donc une préoccupation de premier ordre pour la pile Web3 agentique.

Un agent pourrait avoir besoin de payer sur un réseau, de vérifier des données sur un autre et d’utiliser un service qui effectue le règlement sur un troisième. Une infrastructure inter-chaînes qui gère ce routage de manière invisible – sans que l’agent (ou l’utilisateur) ait à gérer manuellement les ponts et les jetons de gaz – est essentielle pour que cette vision fonctionne dans la pratique.

Ça rejoint l’un des défis persistants du Web3 : l’expérience utilisateur. La gestion des portefeuilles, des clés privées, des frais de gaz et des transferts inter-chaînes a tenu la plupart des gens à distance des services basés sur la blockchain. Les agents IA pourraient absorber toute cette complexité. Au lieu qu’un utilisateur interagisse directement avec l’infrastructure décentralisée, l’agent s’en charge – et l’utilisateur reçoit simplement les résultats.

C’est une proposition vraiment convaincante pour une adoption plus large du Web3. La prochaine interface majeure du Web3 ne sera peut-être pas un portefeuille ou une dApp. Ce sera peut-être un agent IA. Des projets comme l’écosystème crypto et IA de DMCC mettent déjà en place des cadres réglementaires et commerciaux qui anticipent exactement ce type de convergence.

Confiance, responsabilité et les risques qui subsistent

Les agents autonomes posent de réels défis en matière de confiance. Ils agissent plus vite que les humains ne peuvent les superviser, peuvent interagir avec des services inconnus et dépenser de l’argent réel. Des erreurs sont possibles. Tout comme la manipulation : des agents faux ou de mauvaise qualité qui exploitent les systèmes de réputation, des portefeuilles compromis ou des connexions API non sécurisées.

La blockchain aide à résoudre une partie de ce problème. Les enregistrements d’exécution transparents, les règles appliquées par les contrats intelligents, l’identité vérifiable et les historiques de transactions audités réduisent tous la surface d’exposition au risque. Mais la blockchain n’est pas le cerveau d’un agent IA. C’est la couche de responsabilité qui l’entoure. L’agent décide et agit ; la blockchain garantit que ces actions sont enregistrées, autorisées et traçables.

Pour être honnête, l’intégration de l’IA agentique et du Web3 n’en est encore qu’à ses débuts. Les normes sont fragmentées, les questions de responsabilité restent en suspens et les cadres réglementaires n’ont pas encore rattrapé leur retard. Comme pour le problème de positionnement de la tokenisation, la technologie devance souvent les structures de gouvernance et de communication nécessaires à son fonctionnement dans la pratique. L’objectif devrait être une autonomie restreinte : des agents capables d’agir efficacement dans le cadre de règles, de budgets et de structures de responsabilité bien définis – et non des agents opérant sans supervision significative.

Un workflow agentique dans le monde réel : à quoi ça ressemble en pratique

Les noms de protocoles abstraits, c’est une chose. Mais comment la pile Web3 agentique complète se comporte-t-elle réellement dans un scénario concret ? Voici un exemple.

Imaginons qu’une entreprise de logistique souhaite automatiser l’approvisionnement auprès de ses fournisseurs. Elle configure un agent IA avec un mandat clair : trouver un partenaire de fret certifié pour un envoi de Dubaï à Rotterdam, négocier dans le cadre d’un budget prédéfini et finaliser la réservation – le tout sans intervention manuelle.

Voici ce qui se passe en coulisses :

• L’utilisateur définit la tâche et fixe les paramètres dans un portefeuille intelligent : dépense maximale de 8 000 $, catégories de fournisseurs approuvés uniquement, validation humaine requise au-delà de 10 000 $. L’agent se met au travail.
  
• À l’aide de MCP, il se connecte à des bases de données de fret, des API logistiques et des registres de conformité pour récupérer les tarifs en temps réel, les certifications des transporteurs et les exigences réglementaires pour l’itinéraire.
  
• Il a besoin d’aide pour évaluer la conformité en matière de compensation carbone pour la partie européenne du trajet. Il délègue donc cette sous-tâche, via A2A, à un agent spécialisé en conformité. Cet agent vérifie les registres pertinents, confirme le statut de conformité et rend compte.
  
• Avant de s’engager auprès d’un prestataire, l’agent vérifie le profil de réputation ERC-8004 du transporteur. Le transporteur a effectué plus de 400 réservations transfrontalières vérifiées, dispose d’un solide historique on-chain et n’a aucun antécédent de litige. Assez fiable pour continuer.
  
• L’API du transporteur répond par une demande de paiement x402 pour l’acompte de réservation. L’agent vérifie auprès d’AP2 que le paiement respecte les paramètres autorisés. C’est le cas.
  
• Le portefeuille intelligent valide la dépense par rapport aux règles de la politique de l’utilisateur et exécute la transaction. La réservation est confirmée, la transaction est enregistrée on-chain et une piste d’audit complète est créée automatiquement.
  
• L’utilisateur reçoit une notification. Durée totale : quelques minutes. Étapes manuelles requises : zéro.

Pour les entreprises qui explorent comment l’automatisation par l’IA peut alimenter ce type de workflows, les principes sous-jacents s’alignent étroitement sur ce que notre équipe de services d’automatisation IA met en place pour nos clients aujourd’hui. La différence, c’est que l’infrastructure Web3 ajoute les couches de confiance, de paiement et d’identité qui rendent ces workflows vérifiables et économiquement souverains.

À lire également : « 2026 sera l’année des workflows autonomes » explore comment l’automatisation pilotée par l’IA redéfinit plus largement les opérations commerciales.

À surveiller à mesure que la pile agentique mûrit

Les protocoles et normes abordés ici sont encore en cours de développement, mais plusieurs tendances méritent d’être suivies de près :

• L’adoption de x402 pour les micropaiements au niveau des API et la rémunération entre agents
• AP2 qui devient une norme pour l’autorisation vérifiable des paiements d’agents dans les contextes d’entreprise
• Le développement de l’ERC-8004 en tant que couche de confiance et de réputation pour les interactions entre agents sur plusieurs plateformes
• L’infrastructure des portefeuilles intelligents qui mûrit pour prendre en charge des politiques de dépenses complexes impliquant plusieurs agents
• Les micropaiements en stablecoins qui permettent des transactions de machine à machine à grande échelle
• Les places de marché d’agents où des agents IA spécialisés proposent des services à d’autres agents ou utilisateurs

Chacun de ces éléments représente une pièce du puzzle global : une infrastructure Web3 conçue pour faire évoluer les blockchains, qui évolue désormais pour coordonner l’activité numérique autonome à travers les réseaux, les agents et les systèmes économiques.

La pile blockchain modulaire n’est pas seulement une meilleure façon de construire des blockchains. Elle est en train de devenir la couche de coordination et de confiance pour la prochaine génération d’Internet – une génération où les agents IA sont des participants économiques actifs, et pas seulement des outils qui répondent à des questions.

Si tu développes dans ce domaine ou si tu réfléchis à la manière dont l’IA agentique et l’infrastructure décentralisée s’intègrent à ton activité, notre équipe chez what. travaille sur des projets crypto et Web3 à la pointe de cette frontière. Découvre nos services Web3 & Crypto pour voir comment nous pouvons t’aider à t’orienter et à te développer dans ce paysage en pleine évolution.

The post Comment la blockchain modulaire alimente l’IA agentique et le Web3 appeared first on what. AG.

Metro Boutique et le bilan honnête derrière la décision de migrer

Metro Boutique exploite 25 magasins en Suisse et s’adresse à un public de 16 à 34 ans. La boutique en ligne fonctionnait – mais tout juste.

Le système NopCommerce datant de 2015 coûtait 250 000 CHF par an rien qu’en maintenance. Chaque modification de contenu demandait l’intervention d’un développeur, les campagnes Black Friday devaient être activées manuellement à minuit, et la planification automatique n’existait tout simplement pas.

Le moteur principal était économique : les coûts de la plateforme rendaient de plus en plus difficile le maintien d’une rentabilité saine.

Phase 0 : d’abord le business case, ensuite la migration

what. n’a pas démarré par du développement, mais par un Store Check & Migration Shopify Assessment structuré. L’objectif : déterminer sur la base de données concrètes si une migration vers Shopify avait réellement du sens – et si oui, comment la mener.

L’évaluation a fourni des chiffres parlants :

• 55 % d’économies sur le coût total de possession (TCO) sur 5 ans
• 2 millions de CHF d’économies projetées sur la même période
• 9 millions d’URLs dans la boutique existante – dont seulement 88 000 indexées
• Un taux de conversion de 1,04 % comme valeur de départ

Ce business case était défendable en interne. La direction a pu justifier la décision avec des chiffres réels, pas avec un ressenti.

Autre constat tiré de l’évaluation : la forte identité de marque de Metro Boutique vivait avant tout dans les magasins physiques. En ligne, la marque se faisait discrète. « Same brand, different decibels. »

L’environnement système avant et après la migration

Les trois principaux défis techniques – et comment what. les a relevés

Les environnements système complexes ont toujours des points qui semblent simples sur le papier, mais qui ne le sont pas dans la réalité. Chez Metro Boutique, il y en avait trois.

Connecteur Akeneo

Le connecteur existant n’était pas adapté à la structure de données spécifique de Metro Boutique. Le fournisseur réagissait lentement et montrait peu de volonté de s’adapter. what. a donc développé son propre connecteur Akeneo : propre, facile à maintenir et taillé sur mesure pour les besoins réels.

C’est une situation qui arrive plus souvent qu’on ne le pense : les solutions prêtes à l’emploi conviennent rarement à 100 %. La différence, c’est d’être prêt à retrousser ses manches.

Les cartes-cadeaux physiques comme moyen de paiement

Les cartes-cadeaux représentent environ 4 % du chiffre d’affaires en ligne. Le système natif de Shopify n’est pas conçu pour les cartes physiques émises en magasin.

what. a développé une méthode de paiement entièrement personnalisée, qui valide le solde de la carte via le prestataire externe MF Group. Ça peut sembler être un détail – mais laisser filer 4 % du chiffre d’affaires n’était tout simplement pas une option.

À noter : l’ancienne boutique disposait déjà de cette fonctionnalité ; notre développement sur mesure a simplement comblé le vide côté Shopify.

Synchronisation de la liste de souhaits de l’application

La solution tierce initialement évaluée posait des problèmes de synchronisation. what. développe actuellement son propre script. Ce point est encore en cours de mise en œuvre – et on le communique ici en toute transparence, parce que ça fait partie de l’état d’avancement réel du projet.

Chronologie : de l’offre au go-live

Le lancement était initialement prévu pour octobre 2025. Go-live effectif : mi-janvier 2026 – soit environ 7 mois après le démarrage du projet.

Au moment du go-live : aucun temps d’arrêt, aucune perte de données, et toutes les intégrations critiques ont fonctionné parfaitement.

Le calendrier a été décalé parce que la qualité des intégrations primait sur le timing. C’est le bon choix : un go-live avec des points critiques en suspens crée plus de problèmes qu’il n’en résout.

Ce qui a changé depuis le lancement

Denis Spycher, de Metro Boutique, résume la situation :

« En interne, on envisageait depuis un moment de changer de plateforme – surtout à cause des coûts fixes élevés et du manque de flexibilité. Dès le premier jour, j’ai eu un très bon feeling : la collaboration était efficace, orientée résultats et vraiment agréable. Avec Shopify, on a aujourd’hui bien plus de flexibilité, une meilleure efficacité au quotidien et un CMS rapide, intuitif et facile à prendre en main. »

Le taux de conversion est passé de 1,04 % à 1,08 % au cours des 90 premiers jours. Ça peut sembler modeste, mais sur le volume d’un retailer de mode à l’échelle nationale, c’est bel et bien perceptible.

Les changements qualitatifs sont tout aussi significatifs :

• L’équipe e-commerce peut lancer des campagnes en toute autonomie – sans développeur
• 95 % des modifications de contenu sont réalisées en interne
• La planification de campagnes programmées sans activation manuelle est désormais possible (à implémenter)
• Les bases pour la personnalisation, les tests A/B et l’optimisation SEO sont posées
• UX / UI améliorées
• Structure des coûts durablement assainie

Et sur le quotidien de l’équipe :

« Depuis le go-live, on a nettement plus de liberté et on peut agir de façon bien plus proactive. Pour beaucoup de sujets, on ne dépend plus d’une aide externe – on peut intervenir directement, optimiser la boutique et tester rapidement de nouvelles idées. Je suis convaincu que Shopify Plus était le bon choix pour nous. »

Les coûts de la plateforme représentent aujourd’hui environ un quart des dépenses d’avant.

La stack technologique complète

*L’ancienne boutique disposait déjà de cette fonctionnalité ; notre développement sur mesure a simplement comblé le vide côté Shopify.

Ce que ce projet révèle sur la bonne approche de migration

Les projets de migration e-commerce échouent souvent non pas à cause de la technologie, mais parce que la mise en œuvre démarre trop tôt, sans avoir compris le business case.

L’évaluation initiale n’était pas un bonus sympa – c’était le fondement qui a permis à Metro Boutique de prendre et de défendre cette décision en interne. D’abord comprendre, puis décider, puis construire.

Et si un connecteur fournisseur existant ne fait pas l’affaire, what. en développe un lui-même. Ce n’est pas un cas particulier – c’est un principe : les environnements système complexes ont besoin de solutions qui leur correspondent vraiment.

Tu planifies une migration similaire ?

Si les coûts de ta plateforme sont trop élevés, si ton équipe dépend d’un développeur pour chaque modification, ou si tu sais que ton système te freine – alors la première étape, c’est un regard honnête sur la situation actuelle.

C’est exactement ce que proposent nos services de migration Shopify : de l’évaluation initiale à la mise en service, en passant par toute la mise en œuvre technique, et bien au-delà. En tant qu’agence Shopify Plus de référence en Suisse avec plus de 200 boutiques réalisées, on sait où se situent les vrais défis – et comment les résoudre.

The post De NopCommerce à Shopify Plus : comment what. a propulsé Metro Boutique vers l’avenir du e-commerce appeared first on what. AG.

Comment la rédaction IA booste ta visibilité

Le référencement traditionnel mise sur les mots-clés et les classements, mais les algorithmes d’aujourd’hui en demandent bien plus. La rédaction IA, c’est créer du contenu qui aide concrètement les systèmes d’intelligence artificielle à lire, classer et recommander tes pages.

En structurant clairement tes informations, en ajoutant des métadonnées et en maintenant un fil conducteur logique, tu facilites la compréhension de ton intention par l’IA. Cette approche améliore la manière dont ton contenu s’affiche sur les plateformes de recherche et vocales alimentées par l’IA.

Comment utiliser cette checklist d’optimisation IA

Que tu relances ton site web ou que tu cherches à booster ta boutique en ligne, suis ces directives d’optimisation IA et de rédaction IA pour maximiser la cohérence et l’impact.

• Utilise le format questions-réponses
• Ajoute des citations
• Utilise des listes à puces
• Rédige des titres clairs
• Utilise des métadonnées claires
• Inclue des encadrés TL;DR / Résumé ou des points clés
• Utilise des paragraphes courts
• Évite le bourrage de mots-clés
• Crée des liens internes
• Affiche les informations sur l’auteur
• Implémente Schema.org
• Vérifie l’accès au crawl
• Évite de bloquer les bots LLM
• Soumets des sitemaps

Rédaction IA et optimisation pour l’intelligence artificielle – bonnes pratiques

Pour maximiser la visibilité, la rédaction IA doit suivre les bonnes pratiques tant linguistiques que techniques.

Recommandations techniques

Les pratiques suivantes garantissent que les systèmes IA peuvent efficacement crawler, interpréter et représenter ton contenu sur les plateformes de recherche, les réseaux sociaux et les nouvelles plateformes IA.

Visibilité sur tous les canaux

L’optimisation omnicanale garantit que ton contenu est performant sur tous les points de contact : recherche, réseaux sociaux, vidéo et voix. Le cadre des 4P – Présence, Performance, Personnalisation et Persistance – définit comment l’optimisation IA étend la portée de ta marque.

• Présence : optimise les mots-clés et les métadonnées pour la découverte
• Performance : suis les indicateurs de visibilité sur toutes les plateformes
• Personnalisation : adapte le ton et les visuels du contenu en fonction de l’audience
• Persistance : actualise et réoptimise régulièrement le contenu

Aperçu IA de Google

Les aperçus IA présentent des réponses sélectionnées et faisant autorité en haut des résultats de recherche. Être mis en avant ici place ta marque sous les yeux des utilisateurs pendant leurs phases de recherche et de découverte. Cette exposition précoce renforce la notoriété, la confiance et augmente les chances de conversion ultérieure.

À lire également : Tu veux comprendre comment les aperçus IA modifient le comportement de recherche et ce que la recherche zéro clic signifie pour ta marque ? Lis notre guide sur l’optimisation des aperçus IA et la recherche zéro clic.

Directives d’optimisation de contenu pour l’IA

Pour tirer le meilleur parti de l’optimisation IA, ton contenu doit être conçu non seulement pour les moteurs de recherche, mais aussi pour les systèmes d’IA qui l’interprètent et le diffusent sur plusieurs canaux. Commence par te concentrer sur l’intention de l’utilisateur plutôt que sur la densité des mots-clés.

Pour maximiser l’efficacité de la rédaction et de l’optimisation IA, ton contenu doit apporter une réelle valeur ajoutée et éviter les fioritures. Les contenus superficiels, vagues ou trop promotionnels sont souvent ignorés par les systèmes d’IA. Concentre-toi plutôt sur la précision, la clarté et les résultats pour l’utilisateur, et mise sur une expertise authentique en incluant :

• Des perspectives uniques basées sur l’expérience ou la recherche
• Des conseils pratiques que les utilisateurs peuvent appliquer immédiatement
• Des cadres conceptuels propriétaires ou des exemples concrets

Structure ton contenu autour de questions axées sur l’intention de l’utilisateur en utilisant un format FAQ ou Q&A. Les titres doivent imiter le langage naturel de la recherche, par exemple : « Comment l’AIO affecte-t-elle la stratégie SEO ? » Fournis des réponses claires et concises à chaque question.

Décompose les idées complexes à l’aide de listes structurées pour les étapes, les avantages, les fonctionnalités ou les comparaisons. Cela aide à la fois les lecteurs et les modèles d’IA à parcourir efficacement le contenu. Utilise des titres en langage naturel plutôt que des termes abstraits ou techniques :

✔ Quelle est la différence entre AEO et GEO ? 

✘ Cadres d’optimisation IA comparatifs

Garde une mise en forme cohérente pour les titres H2 et H3 afin d’améliorer la lisibilité. Actualise et réutilise régulièrement le contenu en mettant à jour les informations obsolètes, en ajoutant de nouvelles réponses pour refléter l’évolution des comportements de recherche, et en regroupant les articles peu fournis en pages complètes et intemporelles. N’oublie pas d’intégrer de courtes citations attribuées provenant de sources fiables ou d’experts à proximité des affirmations clés pour renforcer la crédibilité.

À lire aussi : Tu découvres l’AIO et le GEO ? Découvre ce que ces termes signifient réellement et pourquoi ils sont importants dans notre article « Du SEO à la recherche IA ».

Directives sur les données structurées

Les données structurées permettent aux systèmes d’IA d’interpréter et d’afficher ton contenu avec précision dans les résultats enrichis. Un balisage correct améliore la visibilité dans les résultats de recherche et les taux de clics, ce qui renforce la façon dont les moteurs de recherche perçoivent ton autorité. Utilise l’outil de test des résultats enrichis de Google et Schema.org pour valider le balisage. Veille à ce que les schémas soient précis et cohérents avec le contenu de la page.

Directives relatives aux citations externes

Les liens externes sont un gage de crédibilité tant pour les utilisateurs que pour les systèmes d’IA. Les références renforcent la confiance et la pertinence contextuelle.

• Crée des liens vers des sources faisant autorité et de haute qualité (par ex. .edu, .gov, publications de premier plan).
• Utilise un texte d’ancrage contextuel qui clarifie la pertinence.
• Mets à jour ou supprime régulièrement les liens rompus.
• Combine les liens internes et externes pour équilibrer le flux d’autorité.

Wikipédia sert de référence clé pour de nombreux modèles de langage (LLM) et est utilisée par des outils de recherche basés sur l’IA générative tels que ChatGPT, Gemini et Perplexity. Des études montrent que près de 10 % de toutes les citations utilisées par ces systèmes d’IA proviennent de Wikipédia, ce qui en fait l’une des sources les plus fréquemment référencées, aux côtés de plateformes telles que Reddit et YouTube.

GEO et rédaction IA – comment elles fonctionnent ensemble

La rédaction IA et le GEO (Generative Engine Optimization) ne sont pas des disciplines distinctes – ce sont les deux faces d’une même médaille. Une bonne rédaction IA fournit aux systèmes d’IA la matière première dont ils ont besoin. Le GEO garantit que ce contenu apparaisse effectivement aux bons endroits.

Lorsque ton contenu est bien structuré, sémantiquement clair et techniquement accessible, tu ne fais pas que faciliter l’exploration de ta page par les moteurs de recherche : tu fournis aux moteurs IA comme ChatGPT, Perplexity et Google AI Overviews les signaux dont ils ont besoin pour inclure ta marque dans les réponses générées.

C’est pourquoi les pratiques décrites dans ce guide soutiennent directement une stratégie GEO plus large. Une mise en forme soignée, le balisage Schema et une structure naturelle de questions-réponses sont autant d’éléments sur lesquels s’appuient les moteurs IA pour décider quel contenu citer.

Assure la pérennité de ta visibilité avec what.

La rédaction IA et l’optimisation IA constituent l’avenir de la croissance numérique. Grâce à des stratégies de contenu structurées et omnicanales dès aujourd’hui, ta visibilité reste résiliente face aux changements algorithmiques. En tant qu’agence GEO de premier plan et agence numérique spécialisée dans le growth hacking, what. assure la pérennité de ta marque en tirant parti de stratégies optimisées par l’IA et GEO qui favorisent la visibilité, la pertinence et des résultats mesurables.

Tu veux savoir où ta marque apparaît réellement dans les réponses générées par l’IA – et où elle n’apparaît pas ? C’est exactement pour cela que notre service GEO a été conçu. Nous suivons ta visibilité IA, identifions les lacunes et optimisons ta présence sur ChatGPT, Perplexity, Google AI Overviews et bien plus encore.

Contacte-nous pour découvrir ton approche de rédaction et d’optimisation IA : réserve ton appel gratuit avec what.

The post Rédaction et optimisation par l’IA – Guide pratique appeared first on what. AG.

C’est un problème de positionnement, et il est sans doute plus dommageable que n’importe quelle limite technique. Si ton public cible ne comprend pas ce qu’il obtient, il n’adhérera pas. Et en ce moment, la plupart des projets d’actifs du monde réel tokenisés vendent de l’infrastructure à des gens qui veulent simplement un rendement.

Nous sommes bien entrés dans l’ère de la tokenisation, et le fossé entre ce que la technologie peut faire et la façon dont elle est vendue ne fait que se creuser.

Le problème central : les gens n’achètent pas des tokens

Voilà la réalité : personne ne se réveille en se disant « Je veux posséder un token. » Les gens pensent aux revenus locatifs, à la diversification de leur portefeuille, à l’accès à des classes d’actifs qui leur étaient jusqu’ici fermées – et à des investissements auxquels ils peuvent réellement faire confiance.

La plupart des projets de tokenisation RWA mettent en avant leur infrastructure. « On tokenise des actifs on-chain. » « Accède à l’immobilier via la blockchain. » Ces messages trouvent peut-être un écho auprès d’un public crypto-natif, mais ils laissent complètement de marbre les investisseurs institutionnels, les particuliers et les professionnels de la finance traditionnelle que ce secteur doit pourtant convaincre.

Un cadrage plus efficace renverse complètement le scénario :

• « Posséder des actifs générateurs de revenus » plutôt que « posséder des tokens »
• « Accès réglementé à l’investissement » plutôt que « exposition on-chain »
• « Une meilleure version de la finance traditionnelle » plutôt que « la DeFi rencontre la TradFi »

Ce n’est pas qu’une question de formulation. Ça reflète un décalage plus profond entre ce que les projets construisent et ce qu’ils communiquent. La tokenisation, c’est l’infrastructure – c’est la plomberie. Ce que les investisseurs achètent, c’est la maison.

Il y a aussi l’illusion de liquidité qu’il convient de mettre en lumière. Beaucoup d’actifs réels tokenisés ne sont tout simplement pas échangés activement. Les marchés secondaires sont peu actifs, les périodes de détention sont longues et les volumes sont faibles. La blockchain ne crée pas de liquidité par défaut – elle vient de la conception du marché, de la distribution et de la demande. Les projets qui promettent de la liquidité sans construire l’infrastructure pour la soutenir s’exposent à un vrai problème de crédibilité.

Une façon simple de comprendre où réside la valeur

Si on réduit la tokenisation à l’essentiel, il y a trois couches – et la plupart des projets se focalisent sur la mauvaise.

• La couche technique est celle qui absorbe le plus d’énergie : infrastructure blockchain, contrats intelligents, normes de tokens. C’est important, mais c’est un moyen, pas une fin.
  
• La couche juridique est celle où la confiance se construit : droits de propriété clairs, soutien réglementaire, droits exécutoires. Sans elle, la couche technique ne sert à rien.
  
• La couche financière est celle où réside la vraie proposition de valeur : rendement, liquidité, accès à des actifs de qualité. C’est ce que les investisseurs achètent réellement.

Les projets qui gagnent vraiment du terrain ne sont pas ceux qui ont la stack technique la plus impressionnante. Ce sont ceux qui ont solidifié les couches juridique et financière, et qui utilisent la technologie comme catalyseur – pas comme argument de vente.

À lire aussi : les bâtisseurs et innovateurs dans l’espace cryptole comprennent de mieux en mieux, en créant des produits qui mettent les résultats en avant et font tourner la blockchain en arrière-plan.

Ce que PRYPCO Mint fait bien

PRYPCO Mint est l’un des exemples les plus parlants de positionnement axé sur les résultats dans l’espace de la tokenisation RWA. C’est une plateforme basée à Dubaï qui permet aux investisseurs de détenir des parts fractionnées dans l’immobilier aux Émirats arabes unis.

Nulle part dans leur message principal on ne parle d’« actif tokenisé » ou d’« exposition on-chain ». L’argument de vente, c’est : « Deviens propriétaire d’un bien immobilier à Dubaï à partir de 2 000 AED. » C’est tout. Clair, direct, et centré sur ce que veulent vraiment les investisseurs.

Ce qui rend PRYPCO Mint intéressant à étudier, ce n’est pas seulement le message – c’est toute la structure qui se cache derrière. La plateforme est intégrée au Département foncier de Dubaï, ce qui signifie que les investisseurs reçoivent des titres de propriété légaux en plus de leurs tokens numériques. La propriété est enregistrée à la fois on-chain et dans les systèmes gouvernementaux. Ça règle l’un des plus grands problèmes non résolus de la tokenisation RWA : la force exécutoire. Le token n’est pas qu’une simple créance – il est lié à un titre de propriété réel, reconnu par les régulateurs.

L’expérience utilisateur suit la même logique. Le marketing met l’accent sur les revenus locatifs, les faibles barrières à l’entrée et l’accession à la propriété. Le jargon technique est réduit au minimum. La plateforme fonctionne aussi en monnaie fiduciaire, donc les utilisateurs n’ont besoin ni d’un portefeuille crypto ni de connaissances préalables en blockchain pour participer.

Les signaux de demande parlent d’eux-mêmes : des biens immobiliers individuels sur la plateforme se seraient vendus en quelques minutes. Ce n’est pas du battage médiatique – c’est l’adéquation produit-marché. PRYPCO ne vend pas de la tokenisation. Il vend l’accès à l’immobilier et aux revenus qui vont avec. La blockchain est le mécanisme de distribution, pas le produit.

Ce qui freine encore une adoption plus large

Même avec des modèles solides comme PRYPCO Mint, le secteur de la tokenisation RWA présente de vrais goulots d’étranglement que le seul fait de mieux communiquer ne suffira pas à résoudre.

• La distribution est le premier. Qui sont les vrais acheteurs, et où les actifs tokenisés se négocient-ils après leur émission ? Beaucoup de projets se lancent sur des plateformes propriétaires sans disposer de canaux établis vers la gestion de patrimoine, le courtage de détail ou l’allocation institutionnelle. Sans distribution, même un produit bien positionné stagne.
  
• La réglementation reste fragmentée d’une juridiction à l’autre. Les exigences de conformité sont élevées, les cadres juridiques pour les titres numériques varient considérablement selon les marchés, et beaucoup de projets naviguent dans ce contexte sans précédent clair. L’écosystème crypto et IA de DMCC est un exemple de la façon dont certaines juridictions s’efforcent de créer des conditions plus claires pour ce type d’innovation.
  
• La confiance reste un problème épineux. Les investisseurs ont besoin d’être assurés que l’actif sous-jacent existe vraiment, que les droits de propriété sont exécutoires et que la plateforme sera encore opérationnelle dans cinq ans. Les contrats intelligents seuls ne suffisent pas – il faut une intégration juridique, un soutien réglementaire et une crédibilité institutionnelle.
  
• L’expérience utilisateur est le quatrième obstacle, souvent sous-estimé. Les portefeuilles crypto ne sont pas adaptés au grand public. Le processus d’intégration sur la plupart des plateformes d’investissement basées sur la blockchain crée de vraies frictions : phrases de récupération, adresses de portefeuille, frais de gas, extensions de navigateur. Des outils comme Privy cherchent à changer ça en proposant des portefeuilles intégrés et des flux d’authentification simplifiés qui masquent entièrement la complexité de la blockchain. L’objectif : une expérience utilisateur comparable à celle de n’importe quel autre produit fintech, avec la blockchain qui tourne discrètement en arrière-plan. Ce fossé existe encore pour la plupart des plateformes RWA, et il limite considérablement la taille du marché potentiel.

Ce que ça implique pour les entreprises du secteur

Si tu développes des solutions de tokenisation RWA, de titres numériques ou d’infrastructures connexes, l’implication stratégique est claire : arrête de mettre la technologie en avant et commence à mettre en avant les résultats.

Ça signifie tester la solidité de ton message par rapport à ce qui intéresse réellement ton investisseur cible. Ça signifie t’assurer que ton cadre juridique et réglementaire est suffisamment solide pour être un atout – pas une simple note de bas de page. Et ça veut dire réfléchir sérieusement à la distribution – pas seulement à la façon dont tu émets, mais à qui achète et où ces personnes te trouvent.

Le secteur de la science décentralisée a été confronté à des défis de positionnement similaires : une technologie véritablement transformatrice qui peine à communiquer sa valeur à des personnes en dehors de la communauté immédiate. Le schéma se répète dans tout le Web3. Les projets qui parviennent à percer sont généralement ceux qui traduisent l’infrastructure en résultats concrets.

La tokenisation dispose de la technologie. La prochaine étape, c’est de construire la crédibilité, la distribution et l’expérience utilisateur qui vont avec.

Prêt à positionner ton projet RWA ou Web3 auprès du bon public ? Notre équipe chez what. travaille avec des startups blockchain, des plateformes de titres numériques et des entreprises crypto-natives pour élaborer des stratégies qui portent leurs fruits. Découvre nos services Web3 & crypto pour voir comment on peut t’aider.

The post Tokenisation des RWA : un problème de positionnement appeared first on what. AG.

Qui est Schweizer Päckli et où est-ce qu’on est intervenu ?

Schweizer Päckli fait quelque chose de plus difficile à réaliser qu’il n’y paraît : ils vendent des colis soigneusement composés, remplis de spécialités régionales suisses authentiques, et ils font en sorte que le tout ressemble à un véritable cadeau plutôt qu’à une simple commande en ligne.

Chaque « Päckli » est assemblé avec soin pour faire découvrir au destinataire un petit bout d’une région suisse spécifique. Le contenu n’est pas générique – les produits sont sélectionnés avec une vraie attention à leur provenance régionale, et c’est ça qui donne tout son caractère au produit. Pour quelqu’un qui cherche à envoyer quelque chose qui a du sens, cette spécificité compte vraiment.

À la mi-2023, l’infrastructure technique qui soutenait tout ça commençait à montrer des signes de fatigue. Chez what., on s’est chargé d’une migration complète de la plateforme, en faisant passer Schweizer Päckli d’OctoberCMS à Laravel et Vue 3, avec Laravel Nova comme backend. Le projet s’est bouclé début 2024.

Pourquoi une migration complète était plus judicieuse que de rafistoler l’ancien système

OctoberCMS avait fait son travail. Mais les limitations s’étaient accumulées au point qu’il n’était plus réaliste de les contourner.

Ajouter de nouvelles fonctionnalités était devenu presque impossible. La dépendance aux plugins du CMS laissait peu de contrôle sur les structures de données sous-jacentes. Et l’expansion vers de nouvelles régions – un véritable objectif stratégique pour Schweizer Päckli – était pour le moins laborieuse.

L’argument en faveur d’une migration complète se résumait à ceci : quand l’architecture elle-même constitue le plafond, les améliorations incrémentielles ne font que repousser l’inévitable. Opter pour Laravel et Vue 3 a donné au projet une base solide :

• De meilleures performances et une extensibilité plus facile
• Des structures de données plus propres avec moins de dépendances aux plugins
• Un backend que le client peut gérer de manière autonome, sans avoir besoin de faire appel à une agence pour les mises à jour courantes

Les défis techniques qui ont ralenti les choses

La mise en place du SSR a été plus difficile que prévu

La partie la plus exigeante du projet a été la configuration du rendu côté serveur (SSR) pour le frontend Vue 3. Comme la boutique de Schweizer Päckli fonctionne comme une application monopage (SPA), c’est le SSR qui la rend explorable et indexable par les moteurs de recherche. Sans ça, la boutique n’existe pratiquement pas pour Google.

Les problèmes venaient d’anciennes bibliothèques JavaScript qui supposaient un environnement navigateur. Dès qu’on essaie de les rendre côté serveur, elles plantent. L’équipe a dû résoudre ces conflits un par un.

Ce qui a compliqué la tâche, c’est une contrainte supplémentaire : le frontend devait rester exactement identique à ce qu’il était auparavant. Le client ne voulait aucun changement visible dans l’interface. L’équipe a donc réécrit les composants internes tout en conservant la même apparence – ce qui a rendu un problème technique en apparence circonscrit nettement plus délicat à gérer.

Migration des données et continuité CSS

Les données existantes devaient être transférées proprement vers de nouveaux schémas, sans perte ni problème d’intégrité. Ce n’est pas le travail le plus passionnant, mais c’est souvent là que les migrations déraillent – discrètement.

La situation avec le CSS et le SCSS était similaire. Des années de feuilles de style datant de l’ère CMS venaient avec leur lot de problèmes habituels : conflits de spécificité, remplacements non documentés, styles liés à du balisage qui n’existait plus. Les faire fonctionner correctement dans les composants Vue 3, sans déclencher une refonte visuelle complète, a demandé beaucoup de patience.

Ce qu’on a appris

Le travail invisible, c’est ce qui compte le plus

Le résultat le plus significatif que personne n’a remarqué, c’est la refonte de la génération de PDF. Les documents fournisseurs ont exactement le même aspect qu’avant en surface. Mais la logique interne a été entièrement reconstruite pour gérer un volume de documents bien plus important que ce que l’ancien système pouvait supporter.

C’est un principe qui vaut la peine d’être intégré : les améliorations qui apportent le plus de fiabilité sur le long terme sont souvent celles que les utilisateurs ne voient jamais. Ce n’est pas une raison de les sauter – c’est au contraire une raison de les protéger contre toute suppression.

Une pile moderne comme condition préalable, pas comme un luxe

Sur l’ancienne plateforme, presque toutes les demandes de nouvelles fonctionnalités se heurtaient au même mur. La réponse revenait toujours à quelque chose comme : « c’est pas possible, ou ça va coûter très cher. » Ce n’est pas seulement un problème technique – ça a des conséquences directes sur l’activité.

Après la migration, ce discours a complètement changé. De nouvelles régions peuvent désormais être ajoutées depuis le backend sans travail de développement. Des fonctionnalités qui étaient auparavant hors de portée sont maintenant faciles à mettre en place.

Les tests automatisés te protègent quand la logique métier évolue

what. a introduit des cas de test qui s’exécutent avant chaque déploiement. Pour une entreprise comme Schweizer Päckli, où la logique autour des colis régionaux, des fournisseurs et des commandes évolue au fil du temps, c’est un vrai filet de sécurité. Ça permet de détecter les problèmes tôt, avant qu’ils n’atteignent les clients.

Ce qui a bien fonctionné

Quelques éléments ont été particulièrement bien mis en place :

• Configuration du CDN : les images, les fichiers JavaScript et CSS sont désormais diffusés via CDN sur les différents domaines régionaux de Schweizer Päckli. Les ressources se chargent plus vite, quelle que soit la version régionale du site sur laquelle le visiteur atterrit. Une décision relativement simple avec un impact disproportionné sur la performance perçue.
• Backend Laravel Nova : le client peut désormais gérer le contenu, les régions et les forfaits sans avoir à faire appel à what. pour les mises à jour courantes. Ce type d’autonomie réduit la dépendance vis-à-vis d’une agence et libère du temps pour les tâches qui nécessitent vraiment une expertise technique.
• Gestion des régions : ajouter une nouvelle région – ce qui demandait auparavant un effort de développement conséquent – est désormais une tâche de backend. Il existe aussi un sélecteur de région qui offre un aperçu rapide de toutes les versions régionales du site, bien utile à mesure que l’entreprise continue de se développer.

Ce qui est encore en cours

La migration était le point de départ, pas la ligne d’arrivée. Schweizer Päckli travaille activement à d’autres améliorations de la boutique – et c’est exactement la bonne approche. La nouvelle architecture prend en charge ce type de développement itératif d’une manière que l’ancien système ne permettait tout simplement pas.

Les sujets en cours incluent des améliorations de la boutique et une expansion régionale plus poussée. L’équipe ne reste pas les bras croisés.

Principaux enseignements de ce projet

Les migrations de plateformes ne sont jamais purement techniques. Les principales contraintes de ce projet étaient d’ordre non technique : conserver l’interface visuellement inchangée, migrer proprement des années de données, et contourner des bibliothèques JavaScript héritées qui n’étaient pas conçues pour les approches de rendu modernes.

Ce qui a créé la valeur la plus durable, ce ne sont pas les livrables les plus spectaculaires. La refonte des PDF, la mise en place du CDN, la suite de tests : ce sont les améliorations structurelles qui, discrètement, éviteront des problèmes pendant des années. Ce sont aussi celles qu’il est le plus facile de supprimer quand les délais se resserrent – et c’est exactement pour ça qu’il ne faut pas le faire.

Si tu utilises un CMS vieillissant et que tu cherches des raisons de repousser une migration, le coût de ce retard est probablement plus élevé qu’il n’y paraît. Chaque demande de fonctionnalité à laquelle on répond « c’est pas possible » a des conséquences commerciales, pas seulement techniques.

Si tu envisages une migration de plateforme ou une refonte de site web, what. aide les entreprises à mener à bien exactement ce type de processus, depuis les exigences et la sélection du système jusqu’à la mise en œuvre et la mise en ligne. Jette un œil aux services de refonte et de développement de sites web de what. pour voir comment on s’y prend.

The post Comment on a migré Schweizer Päckli d’OctoberCMS vers Laravel & Vue 3 appeared first on what. AG.

En collaboration avec l’ETH Zurich, on a développé l’ETH Companion : un coach en leadership IA qui s’appuie exclusivement sur des sources scientifiques et accompagne plus de 3000 cadres de l’ETH. Voici les enseignements sincères qui en découlent.

L’ETH Zurich – Une recherche de niveau mondial

L’ETH Zurich est l’une des universités de recherche les plus prestigieuses au monde. Depuis sa fondation en 1854, elle est synonyme d’excellence scientifique dans les domaines des sciences naturelles, de la technologie, de l’ingénierie et des mathématiques.

Avec plus de 13 000 collaborateurs issus d’environ 120 pays, l’ETH n’est pas seulement une institution suisse, mais un acteur mondial dans les domaines de l’éducation et de la recherche. Ceux qui y travaillent évoluent dans un environnement international extrêmement complexe, avec des exigences en matière de leadership et de prise de décision à la hauteur de ce contexte.

C’est exactement là qu’intervient l’ETH Companion.

Ce qui rend ce coach IA vraiment spécial

Au départ, la question n’était pas d’ordre technique, mais stratégique : comment rendre accessible un coaching en leadership de haute qualité à des milliers de cadres sans investir des sommes colossales dans des programmes de coaching individuels ? Le coaching classique en tête-à-tête ne s’adapte pas à grande échelle. Le coaching numérique, si.

La clé réside dans la qualité de la base de connaissances. L’ETH Companion puise exclusivement ses informations dans des articles fiables rédigés par des psychologues de l’ETH. Pas de contenu provenant de sources Internet aléatoires – uniquement du contenu scientifiquement validé, développé par l’ETH pour l’ETH.

Et ce n’est pas une mince différence. Un programme de coaching en leadership personnalisé coûte rapidement plusieurs centaines de milliers de francs par an – si on veut sérieusement développer le leadership à grande échelle. L’ETH Companion répond exactement à ce besoin : un coaching en leadership scientifiquement fondé, accessible à tout cadre, à tout moment.

Le but n’est pas de créer un chatbot. Il s’agit de créer un outil qui accompagne les cadres face à de vrais défis – en s’appuyant sur des approches qui fonctionnent parce qu’elles sont scientifiquement prouvées.

Ça a l’air simple, mais c’est conceptuellement exigeant. Il faut clarifier très tôt : quels contenus vont être intégrés ? Qui les sélectionne ? Comment s’assurer que le coach reste dans le cadre défini ?

Ces questions doivent être résolues avant même d’écrire une seule ligne de code.

Définir le MVP est plus difficile que le construire

Le moment le plus difficile du projet n’était pas technique : c’était la définition du MVP (Minimal Viable Product).

Qu’est-ce qui doit y figurer ? Qu’est-ce qui viendra plus tard ? Où se situe la frontière entre « assez bon pour être testé » et « trop brut pour montrer une réelle valeur » ? Ces discussions prennent plus de temps que prévu – mais elles sont décisives.

On a travaillé avec l’équipe de l’ETH lors d’ateliers de définition du périmètre, créé des user stories et construit le framework étape par étape. Ça en valait la peine – mais ça prend du temps qu’il faut prévoir.

Un conseil clair : commence petit, puis fais évoluer. Dans le MVP, concentre-toi sur l’essentiel, vérifie que ça marche – et n’ajoute des fonctionnalités supplémentaires qu’ensuite. Ce que tu n’as pas clarifié dans le MVP te coûtera deux fois plus cher plus tard.

Les tests utilisateurs révèlent ce que les documents ne montrent jamais

Le plus beau moment de tout le projet s’est produit pendant les entretiens de tests utilisateurs.

On a vu comment les cadres interagissaient avec le Companion – et leur enthousiasme était palpable. Ça valide non seulement le produit, mais aussi toutes les décisions prises en amont.

Mais les tests utilisateurs nous ont aussi fourni des informations concrètes dont on ne disposait pas auparavant :

• Comment les cadres formulent leurs questions – et ce que ça implique pour la conduite de l’entretien par le coach
• Où le dialogue devenait trop générique et avait besoin de plus de profondeur
• Quels points d’entrée sont intuitifs – et lesquels ne le sont pas

Sans cette phase, le produit aurait été moins bon. Aucun document, aucun test interne ne remplace les interactions réelles.

La sécurité n’est pas une option

Un audit de sécurité faisait partie du processus de développement – et c’était la bonne décision.

Pour un outil basé sur des situations de leadership sensibles et destiné à être utilisé par des milliers de cadres, la sécurité n’est pas un plus. C’est une obligation.

Prévois-le dès le début – pas comme dernière étape juste avant le lancement.

Ce qui compte vraiment : une intégration à long terme, pas une utilisation à court terme

Peu après le lancement, l’attention se porte naturellement sur la question suivante : les utilisateurs sont-ils satisfaits des réponses ?

C’est légitime – mais c’est voir trop court. La véritable vision de l’ETH Companion est autre : le coach de leadership IA doit devenir à long terme une partie intégrante du quotidien professionnel et améliorer durablement la qualité des décisions des cadres.

Et cette vision va encore plus loin : ce qui a été conçu aujourd’hui pour les cadres de l’ETH doit être disponible demain pour les grandes entreprises en dehors de l’ETH – en tant que solution évolutive pour les organisations qui prennent le développement du leadership au sérieux, sans pour autant investir des centaines de milliers de francs dans des programmes de coaching individuels.

C’est une autre échelle. Et elle nécessite d’autres indicateurs que « L’IA a-t-elle donné une bonne réponse aujourd’hui ? »

Ce qu’on a livré – et ce qui va suivre

Le résultat, c’est un coach de leadership IA fonctionnel et stable, avec une conception bien pensée, qui est utilisé de manière productive. Ce qui vient après le lancement est tout aussi important que le lancement lui-même.

On travaille au développement continu par sprints – parce qu’un outil IA de ce type n’est pas un projet achevé, mais un produit vivant.

Ce que tu peux en retenir

Si tu prévois un projet similaire, voici les enseignements qui comptent vraiment :

• La différenciation passe par le contenu, pas par la technologie – la qualité de la base de données scientifiques et l’orientation claire du coach font toute la différence.
• Commence petit, puis fais évoluer – définis par écrit la portée du MVP, valide-la, puis étends-la.
• Les tests utilisateurs ne sont pas facultatifs – planifie-les comme une véritable étape, pas comme une case à cocher à la fin.
• La sécurité et l’évolutivité doivent être prises en compte dès le début, pas après coup.

Tu te demandes à quoi pourrait ressembler concrètement l’automatisation IA dans ton entreprise ? C’est exactement ce à quoi on se consacre chaque jour.

The post Coach en leadership IA de l’ETH Zurich : nos enseignements appeared first on what. AG.

Qu’est-ce que WPBakery ?

WPBakery (anciennement Visual Composer) est un plugin de construction de pages par glisser-déposer pour WordPress. Il te permet de créer des pages visuellement à l’aide d’un éditeur backend, sans écrire une seule ligne de code.

Il existe depuis des années et est fourni avec de nombreux thèmes WordPress premium – ce qui explique en grande partie pourquoi il compte encore autant d’utilisateurs. Ce n’est pas l’outil le plus spectaculaire en 2026, mais il est toujours très présent, et pour de bonnes raisons dans certains contextes.

WPBakery dans la vie réelle : ce qu’un projet client nous a appris

On a travaillé avec un client qui avait besoin d’une refonte de sa page d’accueil et de ses principales pages de destination pour la formation. Le site était déjà construit sur WPBakery, donc changer de constructeur n’était pas envisageable – ça aurait signifié tout reconstruire à partir de zéro, ce qui n’était tout simplement pas rentable.

Notre travail consistait à concevoir et à mettre en place les modèles de page. Le client devait ensuite gérer et remplir le contenu lui-même.

Le nouveau design a été bien accueilli, et on a utilisé Templatera avec des composants réutilisables pour rendre l’éditeur aussi facile à gérer que possible pour le client. Ça a bien fonctionné. Mais certaines choses se sont avérées plus difficiles que prévu, et ça vaut le coup de les connaître avant de te lancer dans un projet similaire.

Certaines sections ont dû rester sous forme de blocs HTML codés en dur, car les reconstruire correctement au sein de la structure de WPBakery aurait pris trop de temps et coûté trop cher. Et puis, WPBakery n’est pas intuitif pour les utilisateurs non techniciens. Même avec des modèles réutilisables en place, notre client a eu besoin d’un accompagnement concret juste pour naviguer dans l’éditeur.

La leçon principale qu’on a tirée de ce projet : WPBakery a du sens quand tu l’utilises déjà. Reconstruire un site en ligne juste pour changer de constructeur en vaut rarement la peine. Mais il est crucial d’avoir des attentes réalistes – concernant la flexibilité, la facilité d’utilisation et ce que l’outil peut ou ne peut pas faire. 

Ces attentes ont directement influencé la façon dont on a évalué les forces et les limites de WPBakery, que nos experts WordPress Janick Lüchinger et Marie Vaxelaire détaillent ci-dessous.

Les points forts de WPBakery

Une remarque avant de commencer : tout ce qui suit concerne uniquement l’éditeur backend. L’éditeur frontend est largement considéré comme peu fiable et lent – la plupart des développeurs expérimentés ne s’en servent tout simplement pas.

Les avantages du point de vue d’un développeur

Notre expert CMS, Janick Lüchinger, a travaillé avec WPBakery sur des configurations existantes et y voit un intérêt évident dans certains cas précis :

• D’un point de vue technique, WPBakery est stable – il ne cause pas de problèmes lorsqu’un site est déjà construit autour de lui.
• De nombreux thèmes premium sont fournis avec des éléments WPBakery natifs et incluent parfois même une licence Pro, ce qui simplifie considérablement la configuration.
• Les éléments personnalisés sont relativement simples à créer, et quand tu sais ce que tu fais, tu as un contrôle total sur la structure HTML.
• Les modèles réutilisables via Templatera aident vraiment à rationaliser à la fois le développement et la remise au client – c’est exactement ce qui nous a sauvé dans le projet ci-dessus.
• Le plugin est activement maintenu, donc la compatibilité avec les versions actuelles de WordPress n’est pas un souci.

Les avantages pour les clients et les utilisateurs

Pour les clients et les utilisateurs qui gèrent eux-mêmes leur contenu, WPBakery est utilisable une fois qu’ils ont été correctement formés. Les mises à jour quotidiennes ne nécessitent aucun codage, et les mises en page réutilisables réduisent le risque de casser accidentellement le design. Ce n’est pas sans friction, mais avec une bonne configuration, c’est tout à fait gérable.

Les véritables limites de WPBakery

C’est là que l’expérience de notre développeuse Marie Vaxelaire prend tout son sens – et ça vaut la peine de lire attentivement si tu envisages d’utiliser WPBakery pour un nouveau projet.

Les inconvénients du point de vue d’un développeur

L’éditeur backend semble dépassé. Sur les pages riches en contenu, on se perd facilement – surtout quand on reprend une page créée par quelqu’un d’autre. Des actions simples comme copier-coller des éléments sont possibles, mais peu pratiques – rien à voir avec le Ctrl+C / Ctrl+V auquel on s’attendrait dans Elementor ou Gutenberg. Ces petites frictions s’accumulent au fil du temps.

Le problème structurel le plus important réside dans la rigidité des éléments natifs. Si ton design a été créé dans un outil comme Figma, indépendamment des contraintes de WPBakery, obtenir un résultat au pixel près est vraiment difficile. Ça nécessite souvent des contournements complexes, du CSS personnalisé et beaucoup d’essais et d’erreurs.

Tu finis souvent par injecter du code personnalisé – ce qui va quelque peu à l’encontre de l’objectif initial d’utiliser un constructeur de pages. Le code HTML généré n’aide pas non plus : les conteneurs profondément imbriqués produisent un balisage surchargé, ce qui nuit à la fois aux performances et à la maintenabilité future.

Les inconvénients pour le client et sur le long terme

Pour les propriétaires de sites qui pensent à long terme, il y a quelques éléments supplémentaires à prendre en compte :

• L’édition assistée par IA est limitée dans WPBakery – tu ne peux pas tirer parti des fonctionnalités modernes d’IA dans ton flux de travail comme tu le peux avec des outils plus récents.
• Changer de solution plus tard est pénible, car le contenu est verrouillé dans des shortcodes ; désactive le plugin et ces shortcodes apparaissent sous forme de texte brut partout sur ton site.
• De nombreux développeurs sont également réticents à reprendre des projets WPBakery en raison de son architecture obsolète, ce qui peut limiter tes options si tu as besoin d’aide extérieure.
• Et si ton développeur s’appuie entièrement sur le constructeur de pages sans connaissances en codage, il risque de se heurter à un mur lorsque WPBakery ne peut pas faire quelque chose de manière native – la solution de secours consiste souvent en une pile de plugins supplémentaires, ou en l’absence totale de solution propre.

WPBakery vs. autres constructeurs de pages : la version courte

Si ton site fonctionne déjà avec WPBakery, le conserver est souvent le choix le plus pragmatique. Reconstruire juste pour migrer n’a que rarement un sens financier – surtout si le site tourne bien et que les clients peuvent gérer le contenu sans trop de difficultés.

Pour les nouveaux projets, c’est une autre histoire. Le constructeur de pages WordPress Elementor offre une expérience d’édition plus moderne, une meilleure intégration de l’IA et un résultat plus propre. Gutenberg, l’éditeur de blocs natif de WordPress, est fourni avec chaque installation de WordPress, évite complètement le verrouillage des shortcodes et est devenu un outil véritablement performant.

Pour les projets nécessitant une configuration rapide et flexible, on opte souvent pour Breakdance. Il combine des pratiques de développement modernes avec une interface épurée et fonctionne bien sans surcharge inutile.

Ces trois outils – Elementor, Gutenberg et Breakdance – constituent de meilleurs points de départ que WPBakery si tu construis un site à partir de zéro en 2026.

WPBakery a toujours sa place dans l’écosystème WordPress – mais pas en tant que premier choix pour les nouvelles constructions.
Tu travailles sur un site WordPress et tu ne sais pas quelle configuration te convient le mieux ? On aide les entreprises à créer, refondre et maintenir des sites WordPress – de la stratégie et la conception au développement et au support à long terme. Découvre nos services WordPress pour voir comment on travaille.

The post WPBakery avantages et inconvénients : une analyse honnête par des experts appeared first on what. AG.

Voici comment, chez what., on a aidé le DMCC à bâtir l’un des hubs blockchain et Web3 les plus actifs des Émirats arabes unis – et ce qu’on en a retenu.

Présentation de la DMCC : pourquoi la plateforme de Dubaï est essentielle pour la crypto et la blockchain

Le DMCC – Dubai Multi Commodities Centre – n’est pas une zone franche de plus. C’est un écosystème soutenu par le gouvernement, conçu spécifiquement pour attirer et accompagner les entreprises de blockchain, crypto, Web3 et IA qui veulent s’établir aux Émirats arabes unis.

Dubaï est accessible en moins de huit heures de vol depuis des marchés qui représentent 65 % du PIB mondial. C’est un avantage géographique bien réel – mais encore faut-il que les bons fondateurs, développeurs et investisseurs le sachent.

L’ambition du DMCC était claire : devenir la destination de référence pour les entreprises de crypto et d’IA dans la région, générer des prospects qualifiés et bâtir une communauté qui apporte une vraie valeur.

C’est là qu’on est entrés en jeu.

Au cœur du DMCC Crypto Centre : un pôle physique pour les entreprises Web3

Le DMCC Crypto Centre, c’est bien plus qu’un espace de coworking. C’est tout un étage de l’Uptown Tower dédié à rassembler sous un même toit les entreprises de crypto, blockchain et Web3.

La proximité physique, dans ce secteur, ça compte vraiment. Pouvoir traverser le couloir et rencontrer ton prochain investisseur ou cofondateur technique crée un effet de réseau qu’aucun groupe Telegram ne peut reproduire.

Le Crypto Centre offre aux entreprises bien plus qu’une simple licence : un accès à un écosystème vivant – conseillers, régulateurs, prestataires de services et autres acteurs, tous dans le même espace.

Cette infrastructure nous a donné quelque chose de concret à mettre en avant.

DMCC AI Centre : une infrastructure pour les entreprises d’intelligence artificielle

À côté du Crypto Centre, le DMCC gère aussi un AI Centre dédié, au même étage de l’Uptown Tower, au sein du même écosystème technologique.

La logique est identique : réunir dans un même lieu physique les startups en IA, les chercheurs et les équipes d’entreprise pour que la collaboration se fasse naturellement. Les secteurs de l’IA et de la crypto partagent des ressources, des événements et un cadre réglementaire qui favorise l’innovation sans friction inutile.

Pour nous chez what., gérer la présence numérique de ces deux secteurs impliquait de bien comprendre leurs recoupements et d’en tenir compte dans notre stratégie de contenu.

Les objectifs du DMCC : génération de leads, positionnement et croissance de la communauté

Le DMCC poursuivait trois objectifs : se positionner comme le premier hub de la crypto et de l’IA aux Émirats arabes unis, générer des leads pour l’octroi de licences auprès d’entreprises qualifiées, et construire une communauté engagée autour de l’écosystème.

Le paysage des licences aux Émirats arabes unis est très concurrentiel. Les zones franches de Dubaï et des autres émirats se disputent toutes les mêmes entreprises Web3 et IA.

Pour se distinguer, le DMCC devait démontrer une vraie valeur communautaire – celle qui vient des événements, des infrastructures partagées et de l’accès aux décideurs.

Notre mission : amplifier cette valeur sur le plan numérique.

Comment what. a géré l’ensemble de la présence numérique du DMCC

Chez what., on a pris en charge toute la présence numérique de l’écosystème technologique du DMCC – en particulier les secteurs crypto et IA.

Concrètement, notre travail couvrait :

• La gestion et le développement de tous les comptes sur les réseaux sociaux : X, Instagram et LinkedIn
• La couverture en direct d’événements physiques sur la blockchain et l’IA à travers les Émirats arabes unis
• L’animation et la modération du serveur Telegram de la communauté DMCC
• La publication d’articles de blog et de communiqués de presse pour soutenir la génération de leads et le positionnement

On ne se contentait pas de programmer des publications. On construisait une infrastructure pour une communauté qui devait se sentir valorisée de l’intérieur et crédible aux yeux du monde extérieur.

Utiliser les événements blockchain et Web3 comme levier de croissance

Au cours de notre collaboration, le DMCC a organisé plus de 25 événements physiques. On en a couvert 24 en direct, en produisant du contenu en temps réel sur Instagram et d’autres canaux.

Mais la couverture en direct n’était qu’une partie de la stratégie. Le travail le plus important, c’était de construire un système autour de ces événements – avec une analyse post-événementielle pour suivre ce qui en ressortait vraiment.

Quelles conversations ont débouché sur des demandes de licence ? Quels sujets ont généré le plus d’engagement ?

Les événements physiques dans l’univers de la crypto et de la blockchain font quelque chose que les réseaux sociaux ne peuvent pas facilement reproduire : ils mettent dans la même pièce des leaders d’opinion, des investisseurs et des builders.

On s’est attaché à capter cette valeur et à la rendre visible en ligne.

Nos plus grands défis : construire une communauté et travailler dans un cadre très contraignant

Une communauté ne grandit que si chacun de ses membres en tire quelque chose. Ça semble évident, mais c’est là que la plupart des efforts de construction d’écosystème s’essoufflent.

On ne peut pas fabriquer un sentiment d’appartenance. Si les personnes de ton écosystème n’en retirent pas de valeur concrète – des connexions, des connaissances, des opportunités – aucune quantité de contenu ne les gardera engagées.

Le DMCC l’a compris dès le départ. Ils ont mis en place une infrastructure physique, organisé des événements réguliers et créé des environnements propices aux rencontres qui comptent vraiment.

Notre rôle : amplifier ce signal sur le plan numérique.

Travailler pour une organisation semi-gouvernementale, ça implique des directives de marque strictes, des processus d’approbation structurés et très peu de marge pour l’erreur.

En début de mission, les workflows d’approbation ont créé des frictions. La publication du contenu prenait trop de temps – ce qui est critique dans un domaine qui évolue aussi vite que la crypto et l’IA.

On a travaillé à améliorer le processus de l’intérieur : identification des goulots d’étranglement, meilleure communication entre les équipes, réduction des allers-retours sans compromettre la conformité.

Résultat : un pipeline plus rapide et plus efficace pour faire approuver et publier le contenu – ce qui a rendu tout le reste possible.

Les résultats de la collaboration entre what. et DMCC

Voici les résultats clés de ce projet :

• Plus de 800 entreprises Web3 et IA agréées à Dubaï via le DMCC
• 24 événements physiques sur la blockchain et la crypto couverts avec du contenu en direct
• Plus de 10 000 membres organiques de la communauté sur les réseaux sociaux

Passer de 500 à 700 entreprises agréées en un an – et continuer au-delà de 800 – illustre bien ce qui se passe quand génération de leads, construction de communauté et positionnement se renforcent mutuellement.

Ce n’était pas une question de publication virale ou d’événement réussi. Il s’agissait de construire un système où chaque élément contribuait au même objectif.

Notre plus grande leçon sur la création de communauté

La principale leçon de ce projet : une communauté, ce n’est pas une stratégie de contenu. C’est une proposition de valeur.

Si les personnes de ton écosystème ne retirent rien de concret de leur présence, aucune quantité de publications ne créera un véritable sentiment d’appartenance.

L’infrastructure physique du DMCC nous a donné, chez what., quelque chose de réel à mettre en avant. Le Crypto Centre, l’AI Centre, les événements, le réseau de plus de 800 entreprises : ce sont de vraies raisons pour un fondateur de choisir Dubaï et le DMCC.

Notre travail consistait à rendre cette valeur visible et convaincante pour le bon public.

Prochaines étapes : construire ton écosystème crypto, blockchain ou IA

Si tu développes ou fais évoluer un projet crypto, blockchain ou IA et que tu cherches une équipe qui comprend à la fois le paysage technique et la façon d’y développer une audience, chez what., on serait ravis d’en discuter.

Découvre nos services de Marketing Web3 et crypto pour voir comment on aborde la création de communauté, la génération de leads et le positionnement des entreprises blockchain et IA.

Ou réserve un appel gratuit pour explorer ce qui est possible pour ton projet.

The post Comment on a fait passer l’écosystème crypto et IA de DMCC à plus de 800 entreprises appeared first on what. AG.