03 / AUTOMATISATION

Automatisations (IA)

Un portefeuille de plusieurs sites et une communauté de plusieurs milliers de membres, gérés à une personne. Ce qui rend ça tenable : des agents IA en production sur les tâches qui demandent du jugement, et des scripts déterministes sur tout ce qui se décrit avec des règles.

AVEC IA

Des agents en production, pas des démos

Assistant IA de support & documentation

Sur splugins.net, un routeur bascule automatiquement entre Claude, Gemini et Kimi selon le modèle demandé. La session Claude tourne avec toute la documentation des plugins en contexte direct : pas de recherche approximative, les réponses citent la vraie doc, pas une version inventée. Une file d'attente absorbe les pics en gérant plusieurs dizaines de sessions en parallèle sans dégrader le temps de réponse.

LLM multi-fournisseurStreamingNode.js

fournisseurs LLM interchangeables (Claude, Gemini, Kimi)

sessions concurrentes gérées par file d'attente

Doc réelle

réponses sourcées sur la documentation à jour, pas inventées

≈10 h/semaine

de support estimées économisées : tickets répétitifs traités sans intervention

Hermes

Un pipeline de release piloté par agents pour la suite de plugins : un agent lit et trie en continu les retours de la communauté Discord via un serveur MCP dédié, puis un enchaînement en huit phases prend le relais : triage, développement, build, tests, publication multi-plateformes, annonces. L'IA accélère chaque étape, mais rien ne part en public sans validation humaine explicite : le verrou est technique, pas une simple convention.

Agents IAMCPDiscord

phases enchaînées, de la collecte à l'annonce

MCP

agent branché en direct sur la communauté

Gate humaine

aucune publication sans validation explicite

≈1 jour/cycle

de triage estimé gagné : les retours Discord sont déjà classés avant que j'ouvre le repo

NotesApp

Un coffre de notes personnel sans base de données, git comme seul historique. Coller un lien, un texte ou partager une image suffit : une session IA résume et range automatiquement. Le coffre expose ensuite un serveur MCP que n'importe quel agent externe peut interroger, la note devenant une base de connaissance consultable.

0 base de données

git comme seul historique

Serveur MCP

coffre interrogeable par d'autres agents

Instantané

résumé et rangement dès l'envoi, aucune action manuelle

SANS IA

Ce qui tourne sur des règles, pas des prompts

L'automatisation ne commence pas à l'IA : une bonne partie du portefeuille tient sur du scripting déterministe : plus rapide, plus prévisible, et plus facile à faire échouer bruyamment quand quelque chose casse.

Résolution automatique de produits Amazon

Un client WebDriver maison pilote un vrai navigateur (relayé depuis le serveur jusqu'à un poste Windows) pour scraper Amazon comme le ferait une personne. Un moteur de résolution tokenise le texte, détecte la marque, extrait les caractéristiques chiffrées et vérifie leur cohérence, pour qu'une canne à pêche de 3 mètres ne résolve jamais vers une référence de 5 mètres. Le produit choisi reste identique partout où le même besoin réapparaît sur le site.

WebDriver BiDiNode.jsAnti-faux-positif

1 060

liens affiliés couverts par le chantier de résolution

Cohérence

marque + caractéristiques chiffrées vérifiées avant validation

≈90 h

de recherche produit manuelle évitées sur les 1 060 liens déjà résolus (estimé à 5 min/lien)

La Factory

Le socle qui fait tourner tout le portefeuille. Un script instancie un nouveau site depuis un template commun et lui attribue port, schéma de base de données et domaine sans jamais entrer en collision avec un site existant, via un registre central, après un vrai incident où un site entier s'est retrouvé remplacé par un autre en production. Un second script, le preflight, refuse la mise en ligne tant que sitemap, métadonnées, images et smoke-test ne sont pas au vert : une definition of done exécutable, pas juste déclarée. Autour, un trio d'outils de recherche de mots-clés et un provisioning GA4 / Search Console entièrement automatisé alimentent un pipeline éditorial qui choisit ses sujets à partir de vraies données de position, pas d'intuition.

Node.jsRegistre centralSEO

sites lancés et exploités depuis le même socle

263+

articles publiés par le pipeline éditorial sur trois sites

Preflight

aucune mise en ligne sans passer la definition of done

≈1/2 journée

gagnée par site au lancement : provisioning GA4 / Search Console / registre automatisé au lieu d'une configuration manuelle

Pipeline de publication multi-plateformes

Publier une mise à jour sur quatre plateformes différentes ne se prête pas à un pipeline aveugle : SpigotMC et BuiltByBit sont derrière une protection anti-bot qui bloque toute automatisation silencieuse. Un outil dédié pilote un vrai navigateur pour remplir et soumettre les formulaires de mise à jour, avec une session assistée qui laisse passer la vérification anti-bot avant de rendre la main à l'automatisation. Pour Voxel.shop, une vraie API developer supprime le besoin de navigateur. Le tout s'enclenche depuis le pipeline de release Hermes, mais seulement après un go explicite : je préfère un système supervisé à un système qui publie seul et se plante en silence.

SeleniumAPI Voxel.shopJava

plateformes de distribution couvertes

API réelle

pour Voxel.shop, sans navigateur piloté

Gate humaine

rien ne se publie sans validation explicite

≈45 min

gagnées par mise à jour : formulaires remplis automatiquement au lieu d'une saisie manuelle sur chaque plateforme

Supervision & alertes

Un cron vérifie un jeu d'URLs canari toutes les 15 minutes et alerte par mail à la moindre panne détectée, en complément de rappels de réservation, de digests météo et de purges de logs programmés sur plusieurs sites du portefeuille.

15 min

fréquence de la vérification anti-panne

Alerte mail

dès la première panne détectée

5 jours

le type de panne évité : une famille de pages restée en 404 pendant 5 jours a déjà coûté du trafic à un site du portefeuille avant ce garde-fou