Le premier pack a été voté
Le pack Ads Skills sera le prochain pack publié par MarkenTIQ, avec un objectif de livraison en septembre 2026 pour sa première version (v0.x). Ce n'est pas une décision de roadmap : c'est le résultat d'un premier tour de vote, 14 voix recueillies auprès des soutiens du projet et d'entreprises externes, dont deux agences de communication, un prestataire de services IA, une entreprise de formation IA et Data et une ETI. Et ces 14 voix sont affichées sur le site avec leur provenance, en toutes lettres, sous le compteur.
Ce détail, la provenance affichée, est en réalité le cœur de l'histoire. Un compteur de votes est une preuve sociale, et une preuve sociale se falsifie en trois clics. Nous avons donc posé une règle, et nous l'avons câblée dans le code plutôt que dans les bonnes intentions : un compteur peut intégrer des votes recueillis hors ligne, mais uniquement si leur provenance est affichée sur la page. Techniquement, un vote initial sans provenance renseignée est refusé par le système. La règle ne dépend pas de la discipline de celui qui administre : elle est dans la machine.
Une mécanique de vote en une journée
Le deuxième tour est ouvert : quatre candidats sont au vote sur le site pour choisir le pack qui suivra Ads Skills. La mécanique derrière cette page a été construite, testée et mise en service en une journée, et elle illustre bien ce que l'agentique (des agents IA capables d'enchaîner des actions, pas seulement de répondre) change à la construction d'un produit.
Le fonctionnement : chaque utilisateur enregistré peut voter, un vote par personne et par sujet. L'enregistrement est vérifié en direct auprès de Brevo, notre outil d'emailing, le même circuit que pour les téléchargements de packs. En base, l'email ne figure nulle part : le vote est enregistré sous une empreinte cryptographique salée, irréversible. Les compteurs sont publics, le résultat oriente réellement ce qui se publie.
Les sujets, eux, viennent de deux sources : nos propositions, étiquetées comme telles, et la boîte à sujets, ouverte à tous les enregistrés. Un sujet déposé n'apparaît jamais directement en ligne : il entre en base avec un statut de modération, invisible du public, en attendant d'être qualifié. C'est le TIQ appliqué à la communauté elle-même : testé pour son intérêt, qualifié, puis publié au vote.
La modération : un agent opère, un humain décide
La modération de cette boîte à sujets préfigure la cible décrite dans l'épisode 3 : un site maintenu au maximum par l'agentique. Concrètement, un agent IA peut lire la file des dépôts, préparer les qualifications, et exécuter les décisions via une interface d'administration qui lui parle aussi bien qu'à un humain. Mais chaque publication, chaque écartement, passe par une validation humaine avant exécution, et chaque action, humaine ou agentique, est journalisée. Un agent propose, un humain décide, la machine garde trace : les deux garde-fous de l'épisode 3, la qualité des informations et la sécurité des contenus, trouvent ici leur première application concrète.
Un arbitrage de construction mérite d'être raconté, parce qu'il est typique des projets de cette taille. Le plan initial prévoyait de stocker sujets et votes dans un simple fichier local, l'option la plus légère. En cours de route, nous avons basculé sur une vraie base de données MySQL, incluse dans notre hébergement mutualisé chez OVHcloud et donc gratuite. Le motif : des fichiers à plat se relisent mal, se sauvegardent mal, et se prêtent mal au travail d'un agent. Une base se requête. Quand la maintenance doit être agentique, la donnée doit être structurée. Coût du changement de cap en cours de construction : moins d'une heure, parce que le code avait été écrit pour rendre ce choix réversible.
Ouvrir des comptes publicitaires avant de savoir s'en servir
Le pack Ads Skills sortira en septembre, et il documentera le pilotage de campagnes B2B outillé par l'IA. Nous ne pouvions pas l'écrire sans avoir ouvert nous-mêmes les comptes, posé nous-mêmes les balises et rencontré nous-mêmes les frictions. Nous avons donc créé un compte Google Ads et un compte LinkedIn Campaign Manager, avant d'avoir la moindre campagne à diffuser. C'est l'ordre inverse de l'habitude, et c'est délibéré : on n'écrit pas une méthode depuis la documentation d'un outil, on l'écrit depuis son usage.
Ce que cette étape apprend sur la répartition des rôles entre l'agent et l'humain est plus instructif que la procédure elle-même. Tout ce qui relève de la configuration a été fait par l'agent : rattacher le compte publicitaire à la page LinkedIn de la marque, vérifier les identifiants de balise, lire les statuts, corriger les réglages, faire le ménage dans d'anciens comptes hérités. Tout ce qui engage juridiquement ou financièrement est resté un geste humain : la création des comptes, la saisie des moyens de paiement, l'acceptation des conditions. Ce n'est pas une limite technique, c'est une règle que nous nous sommes donnée et que nous appliquons partout.
Deux frictions méritent le détour. La première : le profil de paiement Google portait une adresse de facturation qui n'était plus la nôtre. Sans importance apparente, sauf que c'est cette concordance-là que la banque contrôle au moment d'autoriser un paiement. Une adresse périmée, et la première dépense est refusée sans explication utile, le jour où l'on croit lancer une campagne. La seconde : les adresses directes des pages de réglages de Google Ads renvoient une erreur, il faut passer par les menus de l'interface. Anecdotique pour un humain qui clique, bloquant pour un agent qui construit son chemin à partir d'une documentation. Une part du travail d'outillage consiste précisément à cartographier ces pièges-là, et elle n'apparaît dans aucun tutoriel.
Des balises publicitaires derrière un mur de consentement
Trois balises sont désormais posées : Google Analytics pour la mesure d'audience, Google Ads pour la mesure des conversions et la constitution d'audiences, et le LinkedIn Insight Tag pour l'équivalent côté LinkedIn. Aucune ne se charge avant que le visiteur ait accepté le bandeau. Ce n'est pas une option cochée quelque part : le seul mécanisme d'insertion des balises sur le site est écrit à la main, et il ne connaît qu'un déclencheur, le clic sur « Accepter ».
Le détail qui sépare une pose propre d'une pose bâclée tient en une ligne de code. Le script officiel de LinkedIn contient un pixel de repli, destiné aux visiteurs dont le navigateur n'exécute pas de JavaScript. Ce pixel se déclenche sans qu'aucun consentement puisse l'en empêcher, justement parce qu'il ne dépend d'aucun script. Nous l'avons retiré. Coller le code d'une plateforme tel quel dans un pied de page, c'est adopter ses réglages par défaut, y compris ceux qui contredisent le bandeau qu'on affiche par ailleurs.
Deux autres arbitrages ont suivi la même logique. Le texte du bandeau ne parlait que de mesure d'audience ; il parle désormais de mesure et de publicité, parce que c'est ce qui se passe réellement. Et l'import des audiences de remarketing depuis Google Analytics est resté désactivé tant que le bandeau ne couvrait que la mesure. La condition levée, il a été activé. Dans l'autre ordre, nous aurions collecté sous un consentement qui ne portait pas sur cet usage.
Il a fallu aussi élargir la politique de sécurité des contenus du serveur, ce garde-fou qui liste les domaines autorisés à exécuter du code sur nos pages. Le risque était précisément là : une politique trop stricte bloque les balises en silence, et vous croyez mesurer alors que vous ne mesurez rien. Nous avons donc vérifié par le relevé réseau, requête par requête, que les trois balises émettent bien après acceptation. C'est le contrôle qu'on saute quand on est pressé, et qu'on regrette trois semaines plus tard devant un tableau de bord vide.
Dernier réglage, posé le même jour : la correspondance améliorée de LinkedIn, qui rattache une inscription à une campagne. Elle transmet l'adresse email de l'inscrit, transformée en empreinte irréversible dans le navigateur avant tout envoi. L'adresse ne quitte jamais la page en clair, mais l'empreinte reste une donnée personnelle. Nous l'avons donc conditionnée au consentement et ajoutée aux mentions légales avant de l'activer, pas après. L'ordre compte : une mention écrite après coup ne régularise rien.
L'ouverture, et les deux erreurs qui l'ont précédée
Le site est ouvert au public depuis le 1er août 2026. Le geste tient en trois actions : envoyer l'intégralité du dossier de production sur le serveur, supprimer le fichier de mots de passe qui protégeait la pré-production, déclarer le plan du site à Google. Trois actions, et deux erreurs qui les ont précédées. Ce sont les erreurs qui valent d'être racontées, pas la bascule.
La première est une erreur de méthode. Les envois précédents avaient été partiels, et le serveur portait un mélange de versions : le fichier de configuration de la pré-production, celui qui exige un mot de passe, cohabitait avec le fichier d'instructions aux robots de la production. La cause est banale : ces fichiers de configuration commencent par un point et restent masqués par défaut dans les clients FTP. Notre propre documentation de déploiement l'avertissait noir sur blanc. Nous l'avions écrite, nous ne l'avions pas relue. La correction n'a pas consisté à inventorier fichier par fichier ce qui était à jour, mais à tout renvoyer d'un bloc. Quand on ne sait plus dans quel état se trouve un système, on ne le devine pas : on le réécrit entièrement.
La seconde est une erreur de raisonnement, et elle est plus intéressante. Quelques heures avant la bascule, nous avons affirmé que le site était déjà accessible au public. Il ne l'était pas : il demandait toujours un mot de passe. Deux vérifications automatiques avaient pourtant renvoyé un refus d'authentification, et ces deux signaux ont été écartés au motif que le serveur bloquait probablement les robots. Une hypothèse commode a été préférée à une preuve gênante, deux fois de suite. Le navigateur de la personne qui vérifiait gardait les identifiants en mémoire et affichait le site normalement, ce qui rendait l'illusion confortable.
La leçon dépasse notre cas, et elle vaut particulièrement quand une IA travaille à vos côtés : un système ne peut pas prouver son ouverture depuis l'intérieur. Il faut un point de vue non authentifié, et il faut traiter un signal contradictoire comme une information plutôt que comme un bruit à expliquer. Nous l'avons ajoutée à notre retour d'expérience, à côté d'une autre leçon du même jour : avant de recommander un canal de diffusion pour un contenu, établir comment ce contenu est acquis aujourd'hui et ce que cette acquisition mesure.
Le reste s'est déroulé sans incident. La chaîne complète a été éprouvée de bout en bout, dans l'ordre où un lecteur la rencontre : formulaire, email de confirmation, clic de confirmation, page de remerciement, email de livraison, page de téléchargement. Le vote a été testé aussi, refus du second vote sur le même sujet compris. Le plan du site a été soumis à la Search Console, lu par Google, et une demande d'indexation déposée sur l'accueil pour amorcer le passage des robots sans attendre.
Un point a résisté, et il n'est pas entièrement refermé à l'heure où nous publions : les redirections de nos domaines secondaires vers le domaine principal. Elles étaient configurées depuis deux semaines, correctement, et elles ne fonctionnaient pas. Invisible tant que le site demandait un mot de passe, puisque personne ne pouvait tester depuis l'extérieur. Le mécanisme de redirection de l'hébergeur répondait une erreur de service malgré une configuration juste. Nous l'avons contourné en rattachant les domaines à l'hébergement et en écrivant la redirection nous-mêmes, ce qui a un avantage annexe qu'on aurait dû voir plus tôt : le mécanisme de l'hébergeur ne gère pas le HTTPS, le nôtre si, et les navigateurs basculent aujourd'hui en HTTPS par défaut.
Trafic du site : le compteur démarre le jour de l'ouverture, et les premières heures sont dominées par nos propres tests de recette. Publier un chiffre dans ces conditions ne dirait rien d'utile. Le premier relevé honnête sera dans l'épisode 5.
Base email : 4 contacts sur la liste newsletter, 4 sur la liste des packs, nos adresses de test comprises. C'est le vrai chiffre, et il vaut à peu près zéro. Nous le publions quand même, parce que c'est la règle que nous nous sommes fixée et que le point de départ fait partie de l'histoire.
Citations de MarkenTIQ dans les réponses des IA : pas de nouveau relevé. Le précédent portait sur un site que les moteurs ne pouvaient pas lire. Refaire la mesure aujourd'hui reviendrait à mesurer la même chose. Le prochain relevé aura lieu quand les robots auront eu le temps de passer, même panel et mêmes moteurs qu'aux épisodes précédents.
Ce qui a changé depuis l'épisode 3 : un vote communautaire en ligne (un premier tour à 14 voix sourcées, un second tour ouvert avec quatre candidats), une base de données en production, une modération opérable par agent avec validation humaine et journal d'audit, quatre séquences d'emails de suivi après téléchargement, trois balises de mesure et de publicité posées derrière le consentement, et un site accessible sans mot de passe.
Épisode suivant
Au programme, sans promesse de calendrier : la construction du pack Ads Skills en public (c'est le pack que vous avez choisi), les premiers résultats du second tour de vote, les premiers relevés de visibilité du site ouvert, et le retour d'expérience complet de l'acquisition payante outillée par l'IA. Le principe ne change pas : ce journal documente ce qui est fait. Les chiffres seront publiés, bons ou mauvais.
MarkenTIQ · août 2026
Journal de construction, épisode 4. Les autres épisodes sont sur la page du journal.