Études de cas · relevés du 12 octobre 2026
Ce que nous avons construit, et ce que ça mesure
Un agent IA qui répond seul aux voyageurs, un logiciel pour les hébergeurs, un audit de site en une commande, une intégration continue en mémoire vive, des sites rapides et une mesure publicitaire vérifiée. Six systèmes en service, chacun avec ses chiffres et sa limite connue.
01 · Agent IA autonome
Un agent qui gère seul les voyageurs de deux locations saisonnières
Nos propres logements à Saint-Jean-de-Védas servent de terrain d'essai : l'agent y travaille jour et nuit, sur les vraies plateformes, avec de vrais voyageurs.
- messages envoyés seul par l’agent depuis le 26 septembre 2026, tous confirmés par la plateforme
- 71
- séjours accompagnés sur deux plateformes
- 19
- demandes transmises à un humain plutôt que traitées seul
- 35 sur 83
- tests automatisés verts avant chaque mise en production
- 5 457
Le problème
Deux logements loués sur Airbnb et Booking, c'est un flux continu de questions à toute heure, des messages à envoyer avant chaque arrivée, des prix à ajuster et des calendriers à tenir synchronisés. À la main, cela représente une astreinte permanente ; un oubli coûte une mauvaise note.
La limite connue
L'agent transmet encore à un humain près d'une demande sur deux : c'est un choix de prudence assumé, que l'on desserre cas par cas à mesure que les réponses se vérifient.
Ce que nous avons construit
- Un agent qui lit chaque nouveau message, décide s'il peut répondre seul, attend ou transmet à un humain, et justifie chaque décision dans un journal.
- Les messages programmés du séjour partent seuls, au bon moment, sur la plateforme d'origine.
- Les alertes qui demandent un humain (annulation, changement de dates) sont relancées jusqu'à ce que quelqu'un les prenne en charge.
- Les prix sont publiés puis relus sur le gestionnaire de canaux après chaque écriture, et jamais sous un plancher fixé à l'avance.
- Aucun remboursement ni paiement ne part sans validation humaine : l'argent reste hors de portée de l'agent.
Technologies
- TypeScript
- PostgreSQL (Supabase)
- API Beds24
- Serveur dédié
- Telegram
02 · Produit SaaS
Ostalya : transformer un agent maison en produit pour les hébergeurs
Ce que l'agent de location a appris sur le terrain devient un logiciel multi-établissements : planning, assistant voyageurs et réservation directe.
- tests automatisés verts au 11 octobre 2026, dont 291 sur la base de données
- 668
- modifications relues et fusionnées
- 62
- entre le premier commit et le socle actuel
- 11 jours
Le problème
Un agent écrit pour deux logements ne se revend pas tel quel : il faut isoler les données de chaque établissement, résister aux pannes des plateformes et prouver que rien ne fuit d'un client à l'autre.
La limite connue
Ostalya est en construction : aucun établissement extérieur ne l'utilise encore, et les chiffres ci-dessus mesurent la qualité du code, pas un usage commercial.
Ce que nous avons construit
- Un socle multi-organisation où chaque établissement ne voit que ses propres données, verrouillé au niveau de la base.
- Une synchronisation des réservations qui refuse une page de données entière plutôt que d'importer une ligne douteuse.
- Un registre des leçons tirées de l'agent de location, relu avant chaque nouveau lot de fonctionnalités.
- Chaque modification relue par un second modèle d'IA, en plus de la CI, avant d'être fusionnée.
Technologies
- TypeScript
- Cloudflare Workers et D1
- PostgreSQL (Supabase)
- pgTAP
- Vitest
03 · Outil en ligne de commande
Un audit complet d'un site en une commande et une demi-minute
Vitesse, SEO, visibilité dans les assistants IA, sécurité et accessibilité : un seul outil, un rapport lisible par un dirigeant et exploitable par un développeur.
- contrôles en cinq catégories par site audité
- 46 à 47
- par site, rapport compris, mesuré sur trois sites le 12 octobre 2026
- 30 à 33 s
- tests automatisés sur l’outil lui-même
- 97
Le problème
Un premier diagnostic de site demandait d'enchaîner cinq outils, de recopier leurs résultats et de les traduire pour le client. Trop long pour un premier rendez-vous, trop artisanal pour être répété à chaque livraison.
La limite connue
La mesure de vitesse est une mesure de laboratoire : elle repère les défauts techniques, elle ne remplace pas les données des vrais visiteurs, que l'outil sait lire en option.
Ce que nous avons construit
- Une commande qui lit l'accueil et jusqu'à neuf pages internes, mesure la vitesse, contrôle le SEO, les robots des IA, les en-têtes de sécurité et l'accessibilité.
- Un score par catégorie, des priorités classées du plus lourd au plus léger, et un contrôle non mesuré n'est jamais compté comme réussi.
- Des rapports JSON, HTML et PDF, et une comparaison avant / après pour montrer le progrès réel.
- Une action GitHub qui rejoue l'audit à chaque modification et bloque une régression.
Technologies
- TypeScript
- Node.js
- Lighthouse
- axe-core
- Chrome headless
- GitHub Actions
04 · Infrastructure
Une intégration continue auto-hébergée qui travaille en mémoire vive
Chaque modification de chaque site et de chaque application est testée automatiquement sur notre propre serveur, avant toute mise en ligne.
- exécuteurs actifs sur un seul serveur de 12 cœurs, 16 jobs en parallèle au plus
- 64
- en écriture en mémoire vive, contre 163 ko/s sur le disque du serveur
- 437 Mo/s
- pour la CI d’un site e-commerce, contre 573 à 1 552 s avant correction
- 140 s
Le problème
Des dizaines de dépôts testés à chaque modification, c'est un coût en minutes de calcul et des files d'attente. Sur notre premier serveur, les jobs se marchaient dessus et certains tests dépassaient leur délai à cause d'un disque trop lent.
La limite connue
Un seul serveur reste un point unique : l'ancien est gardé en secours le temps de la transition, et le régulateur préfère refuser un job que dégrader tous les autres.
Ce que nous avons construit
- Un serveur dédié qui héberge des exécuteurs propres à chaque dépôt, derrière un régulateur qui refuse un job plutôt que de saturer la machine.
- Les fichiers temporaires des jobs écrits en mémoire vive, avec une purge automatique des restes.
- Des limites de mémoire par exécuteur, pour qu'un job emballé ne fasse jamais tomber les autres.
- La chasse aux pertes de temps mesurées : un cache qui retéléchargeait jusqu'à 1,6 Go à chaque job a été retiré de 49 dépôts.
Technologies
- GitHub Actions auto-hébergé
- Linux et systemd
- tmpfs
- Docker sans privilèges
- Bash
05 · Performance web
Des sites rapides, mesurés en continu et migrés sans coupure
La vitesse n'est pas un argument de plaquette : elle se mesure, se rejoue et se défend à chaque mise en ligne.
- en performance mobile sur trois de nos sites, mesuré le 12 octobre 2026
- 97 à 100
- décalage visuel (CLS) mesuré sur ces trois sites
- 0
- temps d’affichage principal mobile d’un site de réservation, avant et après migration
- 3,0 → 1,9 s
- sites du parc servis par le nouvel hébergement au 12 octobre 2026
- 16 sur 17
Le problème
Un site lent perd ses visiteurs mobiles avant même d'afficher son offre. Et un hébergement qui change ne doit casser ni une adresse, ni un formulaire, ni un classement.
La limite connue
Ces mesures prouvent un niveau technique, pas une hausse de chiffre d'affaires : un site rapide retire un frein, il ne remplace ni une offre claire ni un contenu utile.
Ce que nous avons construit
- Des sites statiques, des polices hébergées sur place et des images au bon format, sans script tiers avant le consentement.
- Une mesure de vitesse rejouée après chaque modification de rendu, en mobile et en ordinateur.
- Une migration d'hébergement site par site : chaque adresse du plan du site comparée avant et après, formulaires testés, retour arrière prêt.
Technologies
- Astro
- Tailwind CSS
- Cloudflare Workers
- Lighthouse
- Playwright
06 · Mesure et tracking
Une mesure publicitaire qui respecte le consentement, prouvée site par site
Google Ads, Meta et Microsoft Ads posés sur un parc de sites, avec une preuve automatisée que rien ne part sans l'accord du visiteur.
- requête publicitaire avant l’accord du visiteur ou après un refus, sur les sites testés
- 0
- scénarios de consentement rejoués sur chaque site
- 3
- balises Microsoft Ads confirmées actives par l’API, la huitième en attente de pose
- 7 sur 8
Le problème
Une balise publicitaire mal posée fausse les résultats ou envoie des données sans accord. Et on ne s'en aperçoit souvent qu'au premier budget dépensé.
La limite connue
Sans clic sur une annonce, aucune plateforme n'enregistre de conversion : la chaîne complète ne sera prouvée qu'avec une première campagne.
Ce que nous avons construit
- Un module de consentement commun à tous les sites, mis à jour en un seul endroit.
- Une recette automatisée dans un vrai navigateur mobile : trois scénarios par site (tout accepter, tout refuser, mesure d’audience seule), chaque requête publicitaire interceptée et comptée.
- Une lecture des comptes publicitaires par leurs API, pour confirmer que chaque balise reçoit bien des visites réelles.
Technologies
- Google Tag Manager
- Consent Mode
- Playwright (WebKit)
- API Google Ads, Meta et Microsoft Advertising
Comment ces chiffres sont produits
Chaque chiffre vient d'une mesure datée : journal de production, résultat de tests d'intégration continue, mesure Lighthouse ou lecture d'une API. Aucun n'est une estimation. Quand un chiffre n'est pas flatteur, il reste : c'est la limite connue de chaque cas.
Les systèmes décrits ici tournent d'abord pour WebTrafic et ses propres sites. Les noms des entreprises clientes ne sont pas cités sans leur accord écrit, et aucune donnée de voyageur ou de visiteur n'apparaît sur cette page.
Pour aller plus loin : nos agents IA, l'automatisation pour les PME et le logiciel sur mesure.
Un processus vous coûte du temps chaque semaine ?
Décrivez-le : nous vous disons ce qui s'automatise, ce qui doit rester humain, et comment le mesurer. Réponse rapide.
Obtenir mon diagnostic