Pourquoi ton agent n'invente jamais une place qui n'existe pas, ne dépasse jamais le ratio de sécurité et ne voit jamais les données d'une autre école ? Ce n'est pas de la chance — c'est l'architecture en dessous : un flux de données en temps réel, des agents qui se gouvernent les uns les autres, et des murs qui scellent chaque école. En production aujourd'hui — sans promesses marketing.
agent · gate de pré-push
suite adverse — à chaque pré-push
propriétaire d'écoleréussi
moniteurréussi
surfeurréussi
tentatives de jailbreakbloquées
verdict du jugevalidé
noyau de sécurité: scellé · le système ne peut pas l'assouplir
TL;DR · 4 chosesEn cours
Un agent gouverné, pas un chatbot
Une seule vérité, des permissions séparées, chaque école isolée — l'agent ne peut ni contourner une règle ni franchir un mur.
Des murs entre les écoles
Filtrage côté serveur + fichier de contexte privé + agent isolé. Zéro lecture entre écoles — fait dans le code, pas dans une politique.
Forecast calibré par spot
Mélange propriétaire + une lecture de la vague spot par spot + des fenêtres ajustées au niveau de chaque cours.
Essaim adversarial au gate de pre-push
Six personas + un juge attaquent notre propre Agent à chaque gate de pré-push. Une règle en échec bloque le push.
0
Tentatives entre écoles bloquées en 90 jours · 0 réussie
93
Cas adverses à chaque push
46
Exécutions avec modèle (7 jours)
6
Personas en CI
Là où le logiciel cesse d'être du hype
Deux ans d'ingénierie des opérations.
L'agent est une fonctionnalité. L'OS en dessous, c'est le moat. Chaque ligne ci-dessous est un système qu'une autre équipe met des mois à copier — pas des semaines.
State-machine des cours
Palier de remboursement (>96h 100%, <24h 0%), no-show, chaîne de report (l'ID du créneau original protège le palier contre le contournement), annulation conditionnelle + cron d'auto-remboursement, split de groupe avec re-dedupe idempotent.
Ledger hash-chain + cron de drift
Chaque événement Stripe est écrit dans un registre en ajout seul, chaîné en SHA-256. Un cron quotidien réconcilie Stripe ↔ DB et signale les écarts. Instantanés chiffrés répliqués hors de la base de données de production, dont une machine physique en dehors du cloud, avec chiffrement par enveloppe AES-256-GCM.
Channel-Manager iCal
Protection SSRF dès la résolution DNS, plafond de taille en streaming, détection automatique de l'encodage, protection empêchant qu'un flux arrivé vide de façon suspecte n'efface les réservations à venir, verrou par flux, STATUS:CANCELLED sortant pour qu'Airbnb libère réellement le créneau.
Forecast par plage
Modèle propriétaire par plage qui lit la vague, le vent, la marée et l'état de la mer ensemble, remonte les alertes océaniques officielles, s'ajuste à la marée et affiche un indicateur de confiance par heure — calé sur la vague au peak, pas sur la lecture au large.
Editais de Praia + ratios SurfBooking
Ratios SurfBooking (1:6 débutant, 1:8 intermédiaire, 1:4 kids, 1:4 privé), validation de l'âge kids, sanity-check du prix (refus en dessous de 10 €), avertissement Editais chaque fois que 2+ moniteurs partagent un cours.
RGPD + protocole admin
Droit à l'effacement sur 20+ tables (le registre fiscal étant conservé), nettoyage du stockage objet pour les avatars et les photos de cours, journal d'audit administrateur sur 30+ actions destructives, OTP par e-mail exigé à chaque action d'un administrateur sur un autre, et garde-fou empêchant deux administrateurs de se verrouiller l'un l'autre.
Agent vocal · en production aujourd'hui
Parle au calendrier. Le calendrier répond.
Deux micros : un en haut du calendrier pour les opérations en lot, un sur la vignette de chaque cours pour les modifications chirurgicales. Aucune commande à mémoriser — portugais naturel, voix native du navigateur.
Sélecteur de la meilleure fenêtre
"Move to the best day this week" → fetches 7 days of forecast, scores per level (wave height range for the level + swell period bonus from 12s + offshore wind direction), picks the top hour, modal shows conditions (1.2m · 8kn · score 7.8/10) before confirm.
Report en lot
"Déplace tous les cours débutants à la semaine prochaine" / "au mois prochain" / "au meilleur jour". Une phrase replanifie des dizaines de créneaux en parallèle, avec les conditions affichées cours par cours — les conflits de staff sont détectés côté serveur avant le commit.
Modifications chirurgicales par cours
Le micro de la vignette du cours connaît le contexte : "Instructeur Pedro" / "Prix 55€" / "6 élèves" / "Duplique au samedi à 10h". Correspondance approximative du prénom avec le staff actif. Sans menus — PUT direct, retour instantané.
N'ouvre jamais l'agent tout seul
Si le parser ne comprend pas la commande, il affiche des exemples dans un toast — on reste dans le calendrier. L'agent ne s'ouvre que si l'utilisateur dit explicitement "ouvre l'agent". Fini le schéma frustrant du "l'IA a essayé de répondre et a empiré les choses".
Tolérance aux erreurs pt-PT
La reconnaissance vocale du navigateur entend "Móvel" au lieu de "Move-a", "Mac me" au lieu de "Marca-me". Le parser normalise avant le regex, accepte "dia 24" / "próxima semana" / "próximo mês", et les nombres en toutes lettres ("cinco alunos") — conçu spécifiquement pour la façon dont les gérants d'écoles de surf portugaises parlent vraiment.
Agent avec le stock en contexte
Demande "combien de combinaisons M ai-je ?" et le chat de l'agent répond à partir d'un bloc de stock pré-calculé dans le system prompt — il n'invente jamais de chiffres. Matériel + quantité en maintenance visibles séparément. Lazy-fetched : il ne coûte pas de tokens sur des requêtes sans rapport.
Le cerveau qui grandit · en production aujourd'hui
Les agents ne font pas que répondre. Ils se souviennent, ils se surveillent — et ils évoluent par la mesure, pas au feeling.
La plupart des fonctions d'IA se figent le jour de leur sortie. La nôtre a une mémoire qui s'accumule, une boucle d'auto-amélioration fondée sur des essais A/B mesurés, et une carte vivante qui montre ses propres points faibles.
Une mémoire qui consolide
Un graphe de connaissances persistant. Chaque règle, amendement et essai mesuré est conservé — pas redessiné de zéro à chaque fois. Les liens qui tiennent dans le temps se consolident et se dessinent plus épais ; l'histoire — même un amendement rejeté — garde sa date. Il ne ment jamais sur le présent ; il ne fait qu'ajouter le passé.
Auto-amélioration, mesurée
L'agent peut proposer des changements à ses propres instructions — chacun testé par un essai A/B (contrôle contre traitement), promu seulement s'il gagne de façon mesurée, avec le retour des écoles réelles comme canari qui retire ce qui a empiré. L'architecture est construite et tourne à la demande ; la boucle autonome nocturne s'allume quand nous le déciderons — sans plafond codé en dur dans la conception.
Un réseau qui se surveille
Une carte vivante dans la console de l'opérateur montre tout le système nerveux — et signale ses propres signaux faibles : un persona de test qui bat l'agent, une proposition qui ne protège aucune règle. L'auto-diagnostic comme fonctionnalité, pas comme défaut — le réseau qui montre ses propres signaux.
En résumé
Une intelligence coordonnée — une seule vérité, trois sorties en temps réel.
Coordination
Un cerveau, une vérité
↓
Sur tout le réseau
Effet de réseau
Intelligence du réseau
Données externes
Vérifié
Sources vérifiées
Par école · Scellé
Isolé
Chaque école isolée
Trois murs par école · filtrage côté serveur · livre de règles épinglé · fichier de contexte privé. Zéro lecture entre écoles.
↓
→ Web · Marketplace
Pages publiques de spot, classements Surf Today, cours à réserver.
→ Application mobile
Check-ins, QR codes, waivers — les opérations sur le sable.
→ Réseau de partenaires
Hôtels et partenaires diffusent des cours par lien/QR.
Différent par conception
Ce n'est pas une fonctionnalité. C'est un choix d'architecture depuis le premier jour.
Des dizaines de sous-systèmes qui se parlent, chacun obsédé par une tranche des opérations de surf — forecast, ratios, waivers, payouts, sync des canaux, attribution, isolement de l'agent. L'intégration, c'est le fossé. Chaque pièce isolée relève d'une ingénierie connue ; la façon dont elles s'alignent autour du fonctionnement réel d'une école de surf, non.
Une plateforme de réservation avec du surf par-dessus, ce n'est pas ça. Une appli de forecast avec des réservations collées derrière non plus.
La couche ouverte — l'intelligence qui se connecte
Le fossé n'est pas une fonctionnalité. C'est un système d'exploitation auquel d'autres — marques, applis, capteurs — se branchent, selon les règles.
Une session, n'importe quel signal
La Couche d'Intelligence traite une Apple Watch, un capteur de planche et une note manuelle comme les flux d'une seule session — chacun avec sa propre horloge, fusionnés côté serveur dans le Passeport du surfeur. Une seule coordonnée voyage au départ, juste pour confirmer que tu étais au spot — et elle n’est jamais enregistrée pour quelqu'un dont l'âge n'est pas vérifié. Aucune trace continue ne quitte l'appareil.
Une API ouverte et MCP
Le forecast par spot, la disponibilité réelle et la création de réservations sont lisibles par n'importe quel marketplace, channel manager ou IA — via des formats standard. Les partenaires se branchent à l'intelligence selon les règles, jamais en les contournant.
Un agent qui ne peut pas mentir
Chaque réponse produite par l'agent passe par un filtre d'honnêteté déterministe avant d'atteindre qui que ce soit : il ne peut jamais inventer une prévision, promettre un remboursement ni divulguer des chiffres d'argent au personnel — en portugais comme en anglais. Ces garde-fous sont verrouillés par un jeu de tests de régression : l'agent peut affiner sa formulation, jamais régresser sur la vérité.
Sécurité au périmètre
Avant qu'une requête n'atteigne nos agents ou notre base de données, elle doit franchir la couche de bordure.
Une bordure enterprise devant tout
Tout le trafic entre par une bordure enterprise — WAF, mitigation DDoS, bot fight mode, filtrage par ASN pays par pays. Les serveurs d'origine ne voient jamais l'internet public en direct ; un attaquant doit d'abord vaincre la bordure.
Rate limiting en couches
Au-delà de la bordure, chaque endpoint sensible a sa propre limite par IP / utilisateur / endpoint — tentatives de connexion, appels d'IA, recherches, listes publiques. Un identifiant compromis ou un scraper créatif est plafonné bien avant de faire des dégâts à grande échelle. Le cost-DoS sur les endpoints d'IA (quelqu'un qui essaie de vider notre budget LLM) est mesuré de la même façon.
TLS uniquement, HSTS, cookies signés
Aucun trafic en clair, nulle part — HTTPS imposé, avec HSTS de 180 jours sur le domaine principal. La clé de renouvellement de session réside dans un cookie HttpOnly à chemin restreint : une session volée ne survit pas à l'onglet. Les points de contact avec le paiement passent par Stripe Checkout / Connect — nous ne voyons jamais les numéros de carte.
Authentification à deux facteurs avec secrets chiffrés
Les propriétaires d'école et les administrateurs peuvent exiger un second facteur — un code à six chiffres depuis une app d'authentification ou un déverrouillage biométrique sur mobile. Les secrets TOTP qui produisent ces codes sont chiffrés au repos avec un algorithme moderne et solide — même un vidage de la base laisse donc le second facteur intact. Les mots de passe sont hachés avec bcrypt + sel ; changer l'email d'un compte révoque toutes les sessions actives de cet utilisateur.
Le système nerveux
Ce qui se passe quand une école crée ou modifie un cours :
1
Origine — SurfBooking OS
Le gérant définit l'heure, le niveau, la restriction de marée, la capacité, le moniteur. Envoyé au cœur de SurfBooking.
2
Validation — ratios de la plateforme + croisement avec le forecast
Le serveur valide le ratio contre le règlement de la plateforme (1:6 débutant, 1:8 intermédiaire, 1:4 kids), confirme les fenêtres de marée, note les conditions et enregistre le résultat.
3
Distribution — trois sorties, en temps réel
Web · Marketplace
Le cours apparaît sur la page publique du spot + les classements Surf Today.
App mobile
Check-ins, QR Codes, waivers. Les moniteurs gèrent la journée sur le sable.
Réseau de partenaires
Hôtels et partenaires diffusent des cours par lien/QR — chaque réservation sait d'où elle vient.
Une intelligence gouvernée, pas un chatbot
Notre IA n'est pas un chatbot avec des instructions. C'est un système gouverné avec des permissions séparées — conçu pour résister au prompt-injection et pour garantir qu'aucune réponse ne traverse un mur qu'elle ne devrait pas traverser.
Garantie · Coordination
Une seule source de vérité
Chaque réponse repose sur l'état réel de la plateforme — réservations, calendrier, mer. Les signaux de l'extérieur n'atteignent jamais le cœur directement : tout est filtré d'abord.
Garantie · Réseau
Le réseau apprend, les écoles restent privées
Des motifs agrégés et anonymisés alimentent l'amélioration continue — effet de réseau — sans jamais partager les données d'une école avec une autre.
Garantie · Données externes
Les sources externes entrent vérifiées
Les données publiques (règlements, sources officielles) sont assainies avant de pouvoir influencer quoi que ce soit — la défense standard contre l'Indirect Prompt Injection.
Garantie · Par école
Chaque école isolée
L'assistant de chaque école est scellé à l'intérieur de cette école, isolé pour le RGPD. Il connaît le contexte local (horaires, matériel, règles de la maison) et ne peut jamais lire les données d'une autre école.
Des murs entre les écoles
Chaque école est un silo scellé. Nous l'appliquons à toutes les couches.
Filtrage côté serveur
Tous les endpoints qui renvoient des réservations, des élèves, du personnel ou du forecast filtrent par l'ID de l'école avant que la moindre donnée ne quitte la base de données. L'interface ne peut pas contourner cela.
Constitution anti-jailbreak
L'assistant IA est lié à un livre de règles épinglé sur le serveur et injecté avant chaque conversation. Il est instruit de ne connaître qu'une seule école, de ne jamais en mentionner d'autres et de respecter les règles de la plateforme même quand l'école insiste sur le contraire.
Ton propre fichier de contexte
Chaque école édite un fichier texte privé que l'assistant lit avant de répondre — tes horaires, ton matériel, tes règles de la maison. Le fichier a une taille limitée, il est journalisé à chaque modification et n'est jamais partagé avec d'autres écoles.
PII retirées avant qu'un modèle ne les voie
Chaque message écrit par un utilisateur passe par une couche de nettoyage qui retire les adresses email, les numéros de téléphone, les identifiants fiscaux, les IBAN et les numéros de carte avant d'atteindre un modèle de langage. La même couche s'applique à la réponse du modèle au retour, si bien qu'un modèle qui en hallucine un ne peut pas le laisser fuir. Les cartes sont détectées par préfixe IIN + contrôle de Luhn ; les autres identifiants par correspondance de forme ancrée. Cette couche est verrouillée contre les régressions par la couche de tests adverses ci-dessus.
Pipeline de forecast
Pourquoi notre 'meilleure fenêtre pour débutants' n'est pas une devinette.
Une confiance honnête, pas une fausse précision
Quand les données ne sont pas sûres, le spot reçoit un badge 'faible confiance' au lieu de faire semblant de savoir. On préfère te dire que c'est limite plutôt que te vendre une fausse précision.
La vague au peak, plage par plage
Le chiffre que tu vois, c'est la vague au peak de cette plage précise — pas la valeur brute au large. Le même swell atlantique arrive sur une pointe exposée et dans une baie abritée avec des hauteurs réelles très différentes, et nous lisons chacune sur son propre terrain.
Des fenêtres pédagogiques par niveau
Nous notons les fenêtres sur tout l'horizon de prévision face aux définitions de niveau du règlement — ce qui compte comme bonne fenêtre pour des débutants n'est pas ce qui compte pour des avancés. La 'meilleure fenêtre' que l'assistant affiche est celle qui correspond au niveau que l'école enseigne.
Couche de défense adversariale
Ce qui tourne contre notre propre Agent avant tout utilisateur réel.
S
Moniteur
Sonde les murs de confidentialité
C
Client
Exige un remboursement · montre sa carte
D
Propriétaire d'école
Teste les limites de charge
M
Multi-tour
Endort puis frappe
Vérification déterministe sur chaque chemin de réponse
Avant qu'une réponse de l'Agent n'atteigne un utilisateur, le texte de l'utilisateur passe par une couche d'assainissement qui retire les identifiants personnels et neutralise les schémas connus de prompt-injection. Cette couche est verrouillée par une suite de tests interne — une nouvelle forme d'attaque apparue in-the-wild reçoit un test de régression apparié avant que le correctif soit considéré comme livré.
Six personas, écrites pour casser le système
Nous entretenons six personas adverses — dont un client frustré, un propriétaire d'école qui pousse l'échelle à bout, un employé qui teste les murs de confidentialité et un attaquant multi-tours qui endort l'Agent sur de nombreux tours avant de frapper — chacun un jeu de rôle détaillé qui sait exactement quoi lâcher (un numéro de carte, une exigence de remboursement, les données d'un collègue) pour faire trébucher l'Agent. Les règles déterministes tournent à chaque contrôle avant push ; les conversations multi-tours avec modèle en direct, qui les déroulent sur des scénarios complets, tournent dans l'essaim adverse (lancé par un opérateur).
Bloque le build, pas de feeling
Une règle en échec n'est pas un avertissement — elle bloque le déploiement. Que la règle soit 'aucun IBAN ne survit à la couche de rédaction' ou 'le rôle staff ne peut pas voir les réservations d'un autre moniteur', le verdict est vérifiable dans le code et binaire. Le copy marketing n'est pas évalué ; seul le comportement l'est.
Diligence en arrière-plan sur chaque candidature d'école
Quand une école demande le badge Partner, un Agent de Vérification lance un balayage en arrière-plan pour que le relecteur humain lise un briefing, pas un formulaire vide.
Fact-check par données publiques
L'Agent de Vérification lance une recherche web isolée (la seule recherche externe de la plateforme), rassemble les mentions publiques de l'école + de la licence déclarée, et marque chaque affirmation comme confirmée / non confirmée / contredite. Chaque fait porte l'URL de sa source pour que le relecteur humain confirme en un clic.
Balayage des biais et des schémas d'avis
Une seconde passe analyse l'empreinte publique d'avis de l'école à la recherche de signaux — campagnes négatives coordonnées, pics de 5 étoiles suspects, schémas déjà bannis. Le résultat est informatif, jamais bloquant ; un risk-score isolé (0-100) arrive dans le briefing pour que le relecteur le pèse.
Briefing scellé — ne revient jamais à la plateforme
Le briefing reste dans une table d'historique de recherche accessible uniquement aux admins. Il n'arrive jamais à une autre école, n'entraîne jamais de modèles, n'apparaît jamais dans le contexte d'une autre école. Seul le relecteur qui ouvre le dossier le voit ; supprimer le dossier supprime le briefing.
C'est l'humain qui décide — toujours
L'agent n'approuve ni ne rejette jamais. Il écrit le briefing ; une personne lit et clique. Chaque approbation et chaque rejet est enregistré avec le briefing joint — pour qu'un régulateur (ou l'école elle-même, si elle le demande) puisse reconstituer exactement ce qui était connu au moment de la décision.
Résilience des données
Ce que nous promettons sur la survie de ton exploitation à n'importe quelle panne.
Journal d'audit append-only + ledger de remboursements chaîné par hash
Les opérations administratives (modifications de compte, élévations de rôle, effacements RGPD) sont écrites dans un journal en ajout seul, conservé par convention. Le rapprochement des remboursements et des versements va un cran plus loin avec une chaîne de hachages côté serveur, si bien qu'une manipulation des flux d'argent se détecte à la relecture.
Sauvegarde répliquée hors de la base de données
Des snapshots chiffrés quotidiens répliqués entre la base de données de production, un fournisseur indépendant d'object-storage et une machine physique dans un autre pays. Perdre un silo = perdre zéro donnée.
Export chiffré en self-service
Chaque école télécharge ses données opérationnelles dans un ZIP AES-256 dont la clé est son propre mot de passe. Même nous ne pouvons pas l'ouvrir. L'export exclut les données personnelles des clients de l'app (elles restent dans le canal de messages SurfBooking) mais inclut tout le reste.
Ce que voient les auditeurs
Sous accord de confidentialité, quand un régulateur demande, nous ouvrons nos contrôles — le code qui prouve que la confidentialité, l'intégrité de la piste d'audit et les purges RGPD fonctionnent comme décrit. Nous n'ouvrons jamais le contenu que ces contrôles protègent : le fichier de contexte de l'école, les prompts de l'assistant, les conversations entre les écoles et l'IA. Audit des contrôles, pas du contenu.
Constitution algorithmique
Les règles qui lient tous les agents.
Tout notre réseau multi-agents est gouverné par des lois épinglées sur le serveur et codées dans les instructions de base de chaque agent (blindées contre les jailbreaks et le prompt-injection). C'est la constitution qui garantit l'isolement entre écoles, l'honnêteté de l'attribution et l'automatisation des paiements de masse sans intervention humaine.