Blog Citios — Insights tech & produit

REX : une après-midi pour rendre le design de Citios Impeccable

Sébastien Quéré — Fri, 07 Aug 2026 00:00:00 GMT

L’été, en théorie, c’est la plage. En pratique, c’est souvent le moment où un CTO freelance regarde son propre site et se dit : « OK… ça tient la route, mais est-ce que j’ai vraiment des règles de design, ou juste des habitudes ? »

Citios tourne bien. Pages services, blog, formulaire, cookies — le socle est sérieux. Mais le design avait grandi par couches : un hero un peu flamboyant, du vert d’eau partout, des contrastes « ça passe sur mon écran », une navigation clavier inégale. Bref, un site de CTO… qui n’avait jamais vraiment eu son atelier design dédié.

Alors j’ai pris Impeccable (un assistant design dans Cursor), un café, et j’ai traité citios.fr comme un petit projet produit d’été. Pas une refonte glossy d’agence. Un passage en revue méthodique : documenter, auditer, corriger, recommencer.

Voici le récit — pour comprendre le principe, même si tu n’écris pas une ligne de code.

C’est quoi Impeccable ? (et comment l’installer)

Impeccable, c’est un outil open source pour les assistants de code (Cursor, Claude Code, etc.). L’idée : au lieu de demander vaguement « rends ça plus beau » — et de récupérer le fameux look IA (dégradé violet, cartes partout, même police partout) — tu disposes d’un vocabulaire de design en commandes : audit, typo, accessibilité, polish, et d’autres. Derrière, des guides + un détecteur de mauvaises habitudes.

En gros : ça transforme l’assistant en directeur design un peu tatillon, avec un brief écrit (PRODUCT.md, DESIGN.md) plutôt qu’en décorateur aléatoire.

Installation (si tu bosses dans Cursor)

À la racine du projet :

npx impeccable install

L’outil détecte ton éditeur, propose une install projet ou globale, et dépose le skill au bon endroit. Tu peux ensuite lancer un audit sur une page, par exemple /impeccable audit.

La doc à jour : github.com/pbakaus/impeccable.

Le point de départ : un site qui « marche », pas un système

Avant Impeccable, Citios avait déjà une identité : bleu marine, vert d’eau (teal), fond clair froid, hero sombre façon terminal. Ça collait à l’offre (CTO hands-on, pas SaaS violet).

Ce qui manquait :

Une intention écrite — pas juste « j’aime ce bleu »
Des règles claires — boutons, contraste, pages claires vs pages sombres
Un filet de sécurité — audits chiffrés, priorités (urgent / important / plus tard)
Des faits produit ancrés — 25 ans dans la tech, 15 ans CTO, 5 postes CTO/DT, pas des chiffres inventés

Sans ça, chaque session avec un assistant, c’est la loterie : il « embellit », tu te retrouves avec des pastilles arrondies et un dégradé indigo. Classic.

Acte 1 — Écrire avant de peindre

Impeccable pousse deux documents que je recommande à quiconque bosse avec un assistant sur l’UI :

PRODUCT.md — le vrai du faux

Qui décide, pour qui, quoi promettre, quoi ne pas inventer. Pour Citios : fondateur non-tech en early-stage en priorité, conversion = conversation (formulaire / prise de rendez-vous), faits d’expérience figés. Zéro faux témoignage client, zéro chiffre magique.

Ça a l’air administratif. En vrai, c’est ce qui empêche l’IA de remplir le site avec du marketing creux.

DESIGN.md — la carte d’identité visuelle

On a ancré :

Intention : « La Passerelle Fondateur ↔ Tech » — lisible pour un CEO non-tech, crédible pour quelqu’un qui code
Couleurs : Marine Atlantique + Teal Signal (le vert d’eau de marque)
Règles : ombres douces, typo lisible d’abord, coins discrets, pas de blanc sur teal vif pour les boutons principaux
Ce qu’on refuse : SaaS violet, néon startup

Photographier l’existant avant de le juger aide aussi : on ne redessine pas un site qu’on n’a pas encore décrit.

Acte 2 — Le choc du premier audit

Premier audit Impeccable : 12/20. Acceptable, pas fier.

La claque principale était le contraste : texte blanc sur le teal de marque. Tous les boutons primaires flamboyants… difficiles à lire. Le genre de truc que tu ne vois plus quand tu es trop habitué à ton propre branding.

Autres alertes classiques :

Couleurs « officielles » d’un côté, couleurs bricolées un peu partout de l’autre
Animations du hero qui bougent même quand on préfère moins de mouvement
Navigation au clavier incomplète
Chiffres produit à clarifier (on a figé 25 ans / 15 ans CTO / 5 postes)

Verdict : le site ressemblait déjà à Citios, mais les règles fuyaient.

Acte 3 — Le problème du teal trop beau

Garder le teal de marque et des boutons lisibles, c’est un vrai casse-tête. Options explorées :

Teal vif + texte marine — le bouton reste marque, mais on abandonne le blanc sur teal
Fond pastel + texte plus foncé — même famille de couleur, bien plus lisible
Bouton contour — transparent + bordure teal

On a choisi la option 2 pour les actions principales. Le teal vif reste l’accent (bordures, hero sombre, soulignements). Sur le fond clair, on n’écrit plus avec le teal flashy : trop faible. On passe par une teinte plus sombre, prévue pour le texte.

Leçon d’été n°1 : une couleur de marque n’est pas automatiquement une couleur de texte.

Acte 4 — Une suite de passes, pas un bouton magique

Impeccable, ce n’est pas « rends tout joli ». C’est une suite de passes avec des jobs différents. Chez moi, ça a ressemblé à ça :

Passe	En clair
Typo	Hiérarchie, interlignage, poids de police plus lisibles
Durcir	Contrastes, focus clavier, formulaire, cookies, zones tactiles
Images & polices	Images mieux servies, polices allégées (la « fancy » surtout au hero)
Header	Plus bas → moins de chrome, plus de contenu
Polish	Détails finaux, messages de succès, stabilité des images blog
Re-audit	Remesurer, classer ce qui reste
Correctifs ciblés	Boutons lisibles sur fond clair, fil d’Ariane sombre, Escape sur les cookies, lien « Aller au contenu »

Score en fin de parcours (à date) : 17/20. Pas un 20/20 marketing — un 17 honnête, avec encore des petits chantiers ouverts.

Leçon d’été n°2 : auditer sans tout corriger d’un coup, puis corriger sans tout réécrire. Résister à l’envie de « tout refaire from scratch » entre deux baignades.

Acte 5 — Amplifier une page, sans tout changer

Après les audits transverses, j’ai voulu un cas ciblé. La commande bolder, ce n’est pas « plus d’effets partout » : c’est une surface, avec le vocabulaire déjà décidé, et le reste intouché.

La demande : rendre la page contact plus affirmée.

Ce qui était mou

La page contact tenait debout, mais elle n’utilisait pas les coups forts du système : pas d’accent teal sur le titre, hero un peu plat, lien FAQ qui détournait de la conversion, titre « Me contacter » mal placé dans le bleu.

Le geste décisif

Hero marine + lueur teal, titre avec accent votre projet
Formulaire seul qui « monte » dans le hero (sur grand écran) — les autres moyens de contact restent sur le fond clair
FAQ sortie du hero (rangée dans le pied de page) — la page contact doit convertir, pas renvoyer lire
Claims inchangés (25 ans / 15 ans CTO)

Tu peux comparer les deux états ci-dessous (glisser le curseur) :

Avant Après

(Captures d’écran réelles de la page contact — avant et après.)

Leçon d’été n°3 : amplifier = une section qui rejoint le niveau d’expression que le reste du site a déjà, pas une nouvelle identité.

Ce qui a vraiment changé sur le site (concret)

Deux registres, une marque

Pages claires : police sobre, marine, ombres douces, boutons pastel lisibles
Hero d’accueil : ambiance terminal, teal qui « pop » sur fond sombre (là, le contraste passe)

Même marque, deux ambiances. Documenté pour que le prochain assistant ne clone pas le terminal sur chaque page service.

Accessibilité sans théâtre

Boutons principaux assez contrastés pour être lus confortablement
Lien « Aller au contenu » branché sur toutes les pages (on en avait oublié deux)
Bannière cookies : Escape = refus, focus remis au bon endroit
Fil d’Ariane lisible sur fond sombre

Petit détail : le lien « Aller au contenu », personne ne le voit… jusqu’au premier Tab. Puis il devient évident pourquoi c’était prioritaire.

Plus léger, plus soigné

Images mieux gérées
Moins de variantes de polices inutiles
Animations du hero respectueuses de « moins de mouvement » quand c’est demandé

Copy & faits

Pas de « 15+ années » floues : 25 ans tech / 15 ans CTO / 5 expériences CTO-DT. Des belles règles de design ne sauvent pas un chiffre faux.

Ce que j’ai appris sur le duo CTO + assistant design

1. Le brief gagne toujours

Si PRODUCT.md et DESIGN.md sont clairs, l’assistant affine. S’ils sont vagues, il improvise — et l’improvisation IA, en design marketing, ça ressemble à tout le monde.

2. Le détecteur se trompe parfois

Il signalait des couleurs « hors palette » : les pastilles rouge/jaune/vert du chrome de fenêtre façon macOS. Normal. Il faut vérifier en contexte, pas tout « corriger » bêtement.

3. Les petits chantiers restants ne sont pas des échecs

Animations encore trop présentes hors hero, quelques tailles de titre hors grille… Ce sont des dettes assumées. Un projet d’été a une fin ; un score 17/20 avec une liste claire vaut mieux qu’un 20/20 fantôme.

4. Le design sert la conversation, pas l’ego

Intention Passerelle Fondateur ↔ Tech = chaque choix doit aider un fondateur non-tech à comprendre l’offre et prendre un créneau. Si le hero est trop « insider », on perd. Si le bouton est illisible, on perd. Le reste, c’est du soin.

Pour qui ça vaut le coup de reproduire ?

Si tu as :

un site marketing déjà en ligne,
une identité visuelle « à peu près là »,
et l’habitude de bosser avec Cursor (ou un assistant équivalent),

…une semaine d’été (ou deux week-ends) sur écrire les règles → auditer → durcir → ré-auditer change plus la qualité perçue qu’une couche de vernis.

Si tu démarres de zéro, Impeccable a aussi des modes pour inventer. Là, on était clairement en mode affinage : garder Citios, enlever le flou.

Et maintenant ?

Le site est plus cohérent, plus lisible, un peu plus rapide à charger, et surtout plus honnête avec ses propres règles. Les petits chantiers restants peuvent attendre le prochain week-end pluvieux (ou la prochaine session entre deux appels clients).

Si tu veux voir le résultat : citios.fr. Si tu veux discuter stack, design ou CTO à la demande — on en parle.

Bon été — et bon audit.

Le Harness en IA — Transformer un modèle brut en agent autonome et fiable

Sébastien Quéré — Sun, 26 Jul 2026 00:00:00 GMT

Un modèle d’IA brut, même très capable, reste une boîte noire. Ce qui le transforme en agent utile en production, ce n’est pas seulement un meilleur prompt : c’est tout ce qu’on construit autour — scripts, outils, planifications, APIs, garde-fous. C’est ça qu’on appelle le harness.

Sur mes projets, ce concept structure BB-DEV (développement autonome) et BB-LOG (monitoring autonome). Voici comment je le vois, et pourquoi l’équilibre entre IA générative et déterminisme change tout.

Partie 1 — Qu’est-ce qu’un harness ?

Plus qu’un wrapper autour d’un LLM

Le harness, c’est l’écosystème déterministe qui entoure le modèle : tout ce qui définit quand l’agent tourne, quoi il a le droit de faire, comment il récupère le contexte, et où il pose le résultat.

Sur le schéma ci-dessus, le « cerveau » au centre est le modèle. Autour, les modules du harness :

Module	Rôle
`tools`	Actions exposées au modèle (lire un fichier, chercher dans le code…)
`mcp`	Connexions vers des plateformes externes (GitHub, Sentry…)
`api`	Interfaces machine-to-machine contrôlées
`cron`	Déclenchement planifié, sans intervention humaine
`scripts`	Étapes déterministes (branche Git, PR, rapport docx…)
`webapp`	Interface humaine pour piloter, valider, consulter

Sans ces briques, on a un chat intelligent. Avec, on a un agent qui s’insère dans un workflow métier.

Pourquoi c’est indispensable

Un modèle générique est polyvalent — et c’est aussi son risque. Il peut dériver, inventer, sortir du cadre. Le harness force la spécialisation : chaque agent a une mission bornée, des permissions limitées, et des étapes critiques qui ne passent pas par la génération libre.

La tendance que je constate : on passe d’agents « fourre-tout » branchés sur plein de MCP à des agents spécialisés, chacun avec un harness taillé pour une tâche précise.

Partie 2 — Cas pratique : le harness de BB-DEV

La mission

BB-DEV traite des tickets GitHub tagués BB-DEV de bout en bout — correctifs bornés, features simples, mises à jour de contenu — sans décision architecturale ni négociation client.

Ce qui est déterministe, ce qui ne l’est pas

Étape	Qui décide
Sélection des tickets tagués `BB-DEV`	Script Python (déterministe)
Génération du code	Claude Code en CLI autonome (IA)
Création de branche, push, ouverture de PR	Scripts / processus Git (déterministe)

L’IA produit le code. Le harness garantit que ce code s’insère dans un workflow de développement classique : même conventions de branche, même revue via PR, même périmètre que j’ai volontairement ouvert avec le tag.

Pourquoi c’était important d’avoir une partie déterministe ? Il y a 3 semaines, j’ai eu un sérieux coup de chaud. Alors que je travaillais avec Cursor pour construire un nouveau Workflow GitHub, je m’aperçois qu’il a décidé tout seul de pousser mon code sur GitHub. Il s’excuse, il me dit qu’il a estimé que comme le travail concernait un Workflow, mes instructions laissaient penser que je l’avais autorisé. Rien de grave, le workflow était opérationnel. Mais cela m’a fait prendre conscience du besoin de limiter l’espace donné à l’agent.

Le résultat

En un mois, 48 tickets traités sans intervention humaine. Le coût de « réentrée » sur les petites tâches disparaît : le développement continue en arrière-plan pendant que je me concentre sur l’architecture et le client.

Et tout ça avec la garantie que le processus de travail de l’équipe sera respecté.

Partie 3 — Cas pratique : le harness de BB-LOG

La mission

BB-LOG audite les erreurs Sentry et crée des tickets GitHub actionnables. Objectif : passer d’un monitoring passif (mail hebdo) à un traitement proactif.

La structure du harness

Cron hebdomadaire — déclenchement déterministe, pas d’oubli.
API Sentry / Posthog — récupération des erreurs avec contexte (fréquence, impact, gravité, évolution, récidive).
Tickets GitHub — vérification des doublons, création de tickets prioritaires selon des règles fixes.
Rédaction IA — la seule partie générative : titre, description, pré-analyse et suggestion de correction, à partir des données déjà structurées par le harness.
Rapport structuré — production d’un docx formaté (processus déterministe), mais c’est une option, car je ne les regarde plus.

L’impact

Des rapports plus riches que le résumé Sentry, et un gain estimé à 2–3 heures par semaine de triage manuel. L’IA rédige ; le harness décide quoi traiter et comment le livrer dans GitHub. Maintenant qu’une partie importante du code de l’agent est déterministe, je sais que je peux l’appeler aussi souvent que nécessaire sans exploser mon budget token.

Ce que ça a changé concrêtement ? BB-LOG vérifie désormais les nouvelles erreurs chaque heure. Et il envoie ces erreurs à BB-DEV qui les corrige dans la foulée. C’est comme si votre application avait une sorte de fonctionnalité auto-repair.

S’il n’est pas certain de la correction, la consigne passée à l’agent est d’ajouter des logs, afin de mieux interpréter la prochaine fois qu’il aura cette erreur. Votre agent améliore au fur et à mesure la maintenabilité de votre application.

Partie 4 — L’équilibre génératif / déterministe

La règle que j’applique

L’IA intervient là où l’intelligence est nécessaire, pas là où la logique suffit.

Récupérer des tickets tagués, ouvrir une PR, planifier un cron, filtrer les erreurs déjà ticketées : ce n’est pas de la créativité. C’est du déterminisme — et c’est précisément ce qui rend l’agent fiable.

La génération (code, texte de ticket, synthèse) reste dans le périmètre où le modèle apporte de la valeur. Le harness borne ce périmètre.

Ce que ça apporte concrètement

Fiabilité — moins de dérives, actions alignées sur le process.
Prédictibilité — on sait ce que l’agent peut faire, et ce qu’il ne fera jamais.
Gestion des risques — permissions minimales, points de contrôle (tag BB-DEV, revue de PR, règles de priorité).
Montée en charge contrôlée — on élargit le harness (nouveaux tools, nouveaux cron) sans lâcher le modèle en liberté totale.

En résumé

Le harness n’est pas un détail d’implémentation : c’est la condition pour qu’un LLM devienne un agent de production. BB-DEV et BB-LOG n’ont pas le même moteur ni le même rythme, mais la même logique : entourer l’IA de processus déterministes, et ne lui confier que ce qui demande vraiment de l’intelligence.

Si vous voulez mettre en place ce type d’agents sur votre stack — ou simplement en discuter — contactez-moi.

Maîtriser l'API Gemini pour les architectures d'agents intelligents

Sébastien Quéré — Sat, 18 Jul 2026 00:00:00 GMT

L’API Gemini ne se limite pas à générer du texte. Bien utilisée, elle permet de construire des agents capables de raisonner, de planifier et d’agir sur des systèmes externes — un dépôt GitHub, une base de connaissances, un board de tickets.

C’est exactement ce que j’ai mis en place pour BB-PO, mon assistant intégré à l’application de gestion de projet Citios. Cet article détaille l’architecture sous-jacente : appels API, ingénierie des prompts, output structuré, et surtout la boucle d’outils qui permet à Gemini d’explorer un repo pour diagnostiquer un bug ou cadrer un ticket.

Partie 1 — Fondations de l’API Gemini

Modèles et capacités

Gemini repose sur une architecture de transformeurs multimodale. En pratique, pour un agent conversationnel métier, on s’appuie surtout sur les modèles de la famille Gemini Pro : bon équilibre entre qualité de raisonnement, latence et coût.

Ce qui change la donne pour les agents, ce n’est pas seulement la qualité du texte généré — c’est la capacité du modèle à décider d’appeler des fonctions (tools) quand il lui manque une information, puis à intégrer le résultat dans sa réponse.

Authentification et environnement

L’API exige une clé, stockée côté serveur (variables d’environnement, secrets manager). Jamais côté client. Dans mon cas, l’agent tourne en fonction serverless ; les headers d’auth sont construits à chaque requête :

const resp = await fetch(`${GEMINI_OPENAI_BASE}/chat/completions`, {
  method: "POST",
  headers: geminiAuthHeaders(),
  body: JSON.stringify(body),
});

Deux modes d’appel : streaming et JSON

Selon le besoin, j’utilise deux wrappers :

Fonction	Mode	Usage
`callGemini`	Streaming (`ReadableStream`)	Conversation interactive, affichage progressif
`callGeminiJson`	Réponse complète (`stream: false`)	Output structuré, boucle d’outils

Le streaming convient à l’UI conversationnelle. La boucle d’outils, elle, a besoin d’une réponse complète pour inspecter les tool_calls avant d’exécuter quoi que ce soit :

async function callGeminiJson(
  body: Record<string, unknown>,
): Promise<
  | { ok: true; message: GeminiCompletionMessage }
  | { ok: false; status: number; text: string }
> {
  const resp = await fetch(`${GEMINI_OPENAI_BASE}/chat/completions`, {
    method: "POST",
    headers: geminiAuthHeaders(),
    body: JSON.stringify({ ...body, stream: false }),
  });
  if (!resp.ok) {
    return { ok: false, status: resp.status, text: await resp.text() };
  }
  const data = await resp.json();
  const message = data.choices?.[0]?.message as GeminiCompletionMessage | undefined;
  if (!message) {
    return { ok: false, status: 500, text: JSON.stringify(data) };
  }
  return { ok: true, message };
}

Partie 2 — Ingénierie des prompts et output structuré

Le system prompt : plus qu’une persona

Un agent utile ne part pas d’un prompt générique. Le message système est assemblé dynamiquement à partir de plusieurs couches :

Persona — nom et posture de l’assistant
Instructions métier — règles du projet, vocabulaire, périmètre
Contexte RAG — extraits de documents uploadés
Mémoires — faits persistés sur l’utilisateur ou le projet
Hints d’outils — quand et comment utiliser GitHub, le calculateur, etc.

let systemMessage =
  personaHeader +
  (system_prompt || defaultPrompt) +
  agentsMdContext +
  githubToolsHint +
  ragContext +
  memoryContext;

const requestMessages: ChatMessage[] = [
  { role: "system", content: systemMessage },
  ...messages,
];

Plus le contexte est précis, moins le modèle invente. Sur BB-PO, chaque projet embarque un fichier de contexte produit : l’assistant sait de quoi on parle sans que l’utilisateur doive tout réexpliquer.

Contexte conversationnel

Gemini ne « se souvient » de rien entre deux requêtes. C’est à vous d’envoyer l’historique complet — messages utilisateur, réponses assistant, et résultats d’outils — à chaque tour. Sans ça, l’agent perd le fil dès qu’il a appelé un tool.

Output structuré : générer un ticket fiable

Pour automatiser la création de tickets, on ne demande pas un paragraphe libre : on impose un schéma JSON strict dans le system prompt, et on passe par callGeminiJson.

const ticketSystemPrompt = `
You are an expert project manager bot. Extract information from the user's
request and generate a technical support ticket as JSON only.
Schema:
{
  "title": "string",
  "description": "string",
  "priority": "High | Medium | Low",
  "assigned_to": "string",
  "steps_to_reproduce": ["string"]
}
No markdown, no text outside the JSON object.
`;

Résultat : un artefact directement injectable dans un board ou une issue GitHub, sans parsing fragile d’un pavé de markdown.

Partie 3 — Architecture des agents avec les Tools

Le principe

Un tool, c’est une fonction que vous déclarez au modèle. Gemini décide quand l’appeler, avec quels arguments. Votre backend exécute la fonction, renvoie le résultat, et le modèle continue — jusqu’à une réponse textuelle finale, ou jusqu’à une limite de tours.

Sans tools, Gemini ne connaît que son entraînement. Avec tools, il peut lire un fichier du repo, chercher une erreur dans le code, explorer une arborescence.

Déclaration des outils

Chaque outil est décrit avec un nom, une description (critique pour que le modèle sache quand l’utiliser) et un schéma de paramètres :

const TOOL_DEFINITIONS = [
  {
    type: "function",
    function: {
      name: "search_github_code",
      description: "Search for code in the project's linked GitHub repository",
      parameters: {
        type: "object",
        properties: {
          query: { type: "string", description: "Search terms or code snippet" },
          max_results: { type: "number", description: "Max results 1–10 (default 8)" },
        },
        required: ["query"],
      },
    },
  },
  {
    type: "function",
    function: {
      name: "read_github_file",
      description: "Read the text content of a file from the linked GitHub repository",
      parameters: {
        type: "object",
        properties: {
          path: { type: "string", description: "Path relative to repo root" },
          ref: { type: "string", description: "Optional branch, tag, or commit SHA" },
        },
        required: ["path"],
      },
    },
  },
  {
    type: "function",
    function: {
      name: "list_repo_tree",
      description: "List files and directories at a path in the linked GitHub repository",
      parameters: {
        type: "object",
        properties: {
          path: { type: "string", description: "Directory path (empty string for root)" },
          ref: { type: "string", description: "Optional branch, tag, or commit SHA" },
        },
        required: ["path"],
      },
    },
  },
];

La boucle d’agent : `runToolAgentLoop`

Cœur du système. À chaque round :

Envoyer system + historique + définitions d’outils
Recevoir une réponse (texte et/ou tool_calls)
S’il n’y a pas d’appel d’outil → réponse finale
Sinon → exécuter chaque outil, pousser les résultats dans la conversation, recommencer

async function runToolAgentLoop(opts: {
  chatModel: string;
  systemMessage: string;
  messages: ChatMessage[];
  toolCtx: ToolExecutionContext;
}): Promise<ToolAgentResult> {
  const conversation: ChatMessage[] = [...opts.messages];

  for (let round = 0; round < MAX_TOOL_ROUNDS; round++) {
    const geminiResp = await callGeminiJson({
      model: opts.chatModel,
      messages: [
        { role: "system", content: opts.systemMessage },
        ...conversation,
      ],
      tools: TOOL_DEFINITIONS,
      tool_choice: "auto",
    });

    if (!geminiResp.ok) throw new AiServiceError(geminiResp.status, geminiResp.text);

    const content = geminiResp.message.content ?? "";
    const roundToolCalls = normalizeToolCalls(geminiResp.message.tool_calls, round);

    if (roundToolCalls.length === 0) {
      return { content: content || "I couldn't generate a response.", tool_rounds: round, tool_calls: 0 };
    }

    conversation.push({
      role: "assistant",
      content: content || null,
      tool_calls: roundToolCalls,
    });

    for (const tc of roundToolCalls) {
      const result = await executeToolCall(tc, opts.toolCtx);
      conversation.push({
        role: "tool",
        tool_call_id: tc.id,
        content: result,
      });
    }
  }

  return {
    content: "Maximum tool rounds reached. Please try a more specific question.",
    tool_rounds: MAX_TOOL_ROUNDS,
    tool_calls: 0,
  };
}

tool_choice: "auto" laisse Gemini décider. MAX_TOOL_ROUNDS évite les boucles infinies (et la facture qui va avec).

Normaliser les appels d’outils

Les tool_calls bruts ne sont pas toujours propres (id manquant, arguments déjà parsés). Une étape de normalisation avant exécution évite des crashs silencieux :

function normalizeToolCalls(
  raw: GeminiCompletionMessage["tool_calls"],
  round: number,
) {
  if (!raw || !Array.isArray(raw)) return [];
  return raw
    .map((tc, i) => {
      const args = tc.function?.arguments ?? "{}";
      return {
        id: tc.id || `call_${round}_${i}`,
        type: "function" as const,
        function: {
          name: tc.function?.name ?? "",
          arguments: typeof args === "string" ? args : JSON.stringify(args),
        },
      };
    })
    .filter((tc) => tc.function.name);
}

Scénario concret : diagnostiquer un bug via GitHub

Voici le type de flux que la boucle produit quand un utilisateur décrit une erreur :

Utilisateur — « La connexion échoue avec InvalidCredentialsError. »
Round 1 — search_github_code(query="InvalidCredentialsError") → localise les fichiers concernés
Round 2 — read_github_file(path="src/auth/service.ts") → lit le service d’auth
Round 3 — réponse textuelle : explication + pistes (dépendance externe, validation des credentials, etc.)

L’agent n’invente pas le chemin du fichier : il le découvre. C’est la différence entre un chatbot qui « a l’air de savoir » et un assistant qui vérifie dans le code.

Partie 4 — Déploiement et bonnes pratiques

Serverless

L’endpoint tourne en fonction serverless (Supabase Functions / Deno). Le handler parse la requête, construit le system prompt, et bascule vers runToolAgentLoop ou le streaming selon le flag use_tools.

Logging

Sans logs structurés, une boucle d’outils est opaque. Je journalise systématiquement : modèle, usage des tools, nombre de rounds, durée, taille de réponse, erreurs.

function logChatInvocation(summary: ChatInvocationLog): void {
  const parts = [
    "[chat]",
    `status=${summary.status}`,
    `model=${summary.model}`,
    `tools=${summary.use_tools}`,
    `project=${summary.project_id ?? "none"}`,
    `msgs=${summary.messages}`,
    `duration_ms=${summary.duration_ms}`,
  ];
  if (summary.tool_rounds != null) parts.push(`tool_rounds=${summary.tool_rounds}`);
  if (summary.error) parts.push(`error=${summary.error}`);
  console.log(parts.join(" "));
}

Ce que je retients en production

Tokens et coût — l’historique + le contexte RAG + les résultats d’outils grossissent vite. Tronquez, résumez, limitez MAX_TOOL_ROUNDS.
Prompts précis — rôle, schéma, exemples few-shot quand le format compte.
Validation — parser et valider le JSON de sortie avant de l’injecter dans un système aval.
Sécurité — clé API serveur uniquement ; tokens GitHub à scopes restreints (lecture repo, pas admin) ; valider les chemins demandés par les tools.
Permissions minimales — un outil qui lit un fichier n’a pas besoin d’écrire une issue.

En résumé

Brique	Rôle
`callGemini` / `callGeminiJson`	Streaming UI vs réponses structurées / tools
System prompt dynamique	Persona + contexte projet + RAG + hints tools
`TOOL_DEFINITIONS`	Contrat entre le modèle et votre backend
`runToolAgentLoop`	Orchestration multi-tours jusqu’à la réponse finale
Outils GitHub	Explorer, lire, chercher dans le dépôt lié

Gemini devient intéressant pour le métier le jour où il cesse d’être un générateur de texte isolé et commence à agir — avec des garde-fous, des logs, et des tools dont vous contrôlez le périmètre.

Si vous voulez voir ça en action côté produit, BB-PO en est l’illustration concrète. Et si vous voulez en discuter pour votre stack, contactez-moi.

BB-PO — l'assistant IA qui répond à vos questions projet et rédige vos tickets

Sébastien Quéré — Tue, 07 Jul 2026 00:00:00 GMT

Partie 1 — Un assistant, pas un agent

La différence compte

J’ai déjà présenté ici deux agents IA autonomes que j’utilise au quotidien : BB-DEV, qui développe des tickets de bout en bout, et BB-LOG, qui surveille les erreurs en production. Ces deux-là tournent seuls, sur des cycles automatisés, sans que j’aie besoin de les solliciter.

BB-PO fonctionne différemment. C’est un assistant, pas un agent : il ne se déclenche jamais tout seul. Il répond uniquement quand on lui pose une question ou qu’on lui demande quelque chose, exactement comme on ouvrirait une conversation avec ChatGPT. Pas de cron, pas de boucle autonome — juste une interface de discussion, disponible à la demande.

Où il vit

BB-PO est intégré directement dans l’application de gestion de projet que j’utilise avec mes clients, celle qui est synchronisée avec GitHub pour le suivi des tickets et l’avancement du board. C’est là tout l’intérêt : l’assistant n’est pas une IA générique à côté de l’outil, il a une vision complète du projet en cours — les tickets, leur statut, leur historique.

Partie 2 — Ce que BB-PO sait faire

Répondre aux questions sur le projet

La première fonction de BB-PO, c’est de répondre aux questions qu’on lui pose sur un projet : où en est telle fonctionnalité, qu’est-ce qui a été livré la semaine dernière, quels tickets sont encore ouverts sur tel sujet. Comme il a accès au board complet, il ne devine pas — il répond à partir de l’état réel du projet.

Créer un ticket d’évolution

Quand on lui décrit un besoin d’évolution, BB-PO ne se contente pas de créer un ticket avec la première formulation venue. Il pose des questions pour affiner la demande : quel est l’objectif, qui est concerné, qu’est-ce qui doit changer précisément. Le tout sans jamais devenir technique — l’échange reste au niveau du besoin, pas de l’implémentation.

Créer un ticket de bug

Pour un bug, la logique d’échange change. BB-PO demande :

les conditions de reproduction du problème,
les symptômes observés,
le comportement attendu à la place.

Ce cadrage systématique évite les tickets de bug bâclés — ceux qui arrivent avec une phrase du type « ça ne marche pas » et qu’il faut ensuite reprendre par email ou en réunion pour comprendre ce qui s’est réellement passé.

Fonction	Ce que fait BB-PO
Question projet	Répond à partir de l’état réel du board et des tickets
Ticket d’évolution	Pose des questions de cadrage fonctionnel, sans jargon technique
Ticket de bug	Demande reproduction, symptômes, comportement attendu
Déclenchement	Uniquement sur sollicitation — jamais automatique

Partie 3 — Sous le capot

Le moteur IA : Gemini

BB-PO s’appuie sur l’API Gemini — pas une interface grand public, mais une intégration directe dans l’application. Le choix n’est pas anodin : pour une interface conversationnelle exposée à des utilisateurs finaux, avec des temps de réponse rapides et un coût maîtrisé à l’usage, c’est le moteur qui correspondait le mieux à ce besoin précis.

Mais un modèle seul ne suffit pas. Pour que BB-PO réponde utilement sur un projet précis, il faut lui donner du contexte — et lui donner les moyens d’aller chercher l’information qu’il n’a pas encore.

Un fichier de contexte projet, injecté dans ses instructions

Chaque projet embarque un fichier de contexte qui décrit le produit, ses utilisateurs, son vocabulaire métier et ses règles de fonctionnement. Ce fichier est chargé dans les instructions système de l’assistant à chaque conversation. BB-PO ne part pas de zéro : il sait de quoi on parle, quels termes utiliser et quel périmètre couvre le projet — sans que l’utilisateur ait à tout réexpliquer à chaque échange.

Des tools pour accéder au code

La lecture du board seule ne suffit pas toujours pour répondre à une question. Quand il faut comprendre comment une fonctionnalité est réellement implémentée, BB-PO dispose de tools qui lui permettent de consulter le dépôt : parcourir l’arborescence, lire un fichier, chercher dans le code. Il va chercher l’information à la source plutôt que de supposer — tout en restant dans son rôle d’assistant produit, sans basculer dans un échange technique inutile pour l’utilisateur.

Un niveau comparable à Claude Cowork, avec le board en plus

En termes de qualité d’échange et de compréhension du contexte, le niveau de réalisation de BB-PO est comparable à celui de Claude Cowork. La différence, c’est que BB-PO a en plus la vision directe du board du projet — pas une liste de tickets brute, mais une vue kanban de toutes les tâches.

Ce qu’on entend par « board »

Le board, c’est la liste des tâches du projet affichée en vision kanban : des colonnes qui représentent les étapes d’avancement, des cartes qui se déplacent au fil du travail. C’est le même principe que ce qu’on retrouve dans des outils comme Hermes Agent — une lecture immédiate de l’état du projet, sans avoir à fouiller dans GitHub.

Chaque ticket y figure avec son état précis : à cadrer, en cours, en revue, livré… BB-PO voit où se situe chaque demande, de sa création jusqu’à sa livraison. Quand on lui demande « où en est telle évolution ? », il ne répond pas à partir d’une impression générale — il lit la colonne dans laquelle se trouve le ticket, et l’historique qui l’a amené là.

C’est ce qui distingue BB-PO d’un assistant conversationnel classique : il ne travaille pas dans l’abstrait. Il connaît l’état réel de ce qui a été fait, de ce qui est en cours, et de ce qui reste à faire — parce que le board en est la source de vérité.

Partie 4 — Une nouvelle offre : ouvrir l’application aux clients

Pourquoi maintenant

Jusqu’ici, l’application de gestion de projet et ses assistants IA — BB-PO compris — étaient un outil interne, réservé à mon usage pour piloter les missions. La nouvelle offre change ça : j’ouvre désormais l’application aux clients qui le souhaitent.

Deux cas d’usage concrets :

Après un MVP : garder la main sur le suivi du produit, poser des questions à BB-PO, faire remonter des évolutions ou des bugs directement, sans dépendre d’un aller-retour par email.
Pour booster une équipe avec des agents autonomes de développement type BB-DEV : une équipe existante gagne en vitesse en déléguant les tickets bien cadrés à un agent IA, pendant que BB-PO reste le point d’entrée conversationnel pour cadrer les demandes.

Ce que ça change pour vous

Avoir accès à l’application, c’est avoir une vision transparente et en temps réel de l’avancement — sans filtre, sans rapport hebdomadaire à attendre. Et avec BB-PO, c’est aussi pouvoir poser une question ou déclarer un bug à n’importe quel moment, sans avoir à formuler un ticket GitHub techniquement parfait du premier coup.

Si l’ouverture de cette application à votre équipe, ou l’ajout d’agents IA autonomes pour booster votre développement, vous intéresse, contactez-moi — j’en parle avec plaisir.

Agent BB-LOG — Quand l'IA surveille les logs à ma place

Sébastien Quéré — Tue, 16 Jun 2026 00:00:00 GMT

Partie 1 — Le problème des erreurs en production

Les erreurs existent. La question c’est comment on les traite.

Dans toute application en production, des erreurs se produisent. C’est inévitable. La vraie question, c’est : est-ce qu’on les voit ? Est-ce qu’on les comprend ? Est-ce qu’on agit dessus dans un délai raisonnable ?

Sentry, l’outil de monitoring d’erreurs que j’utilise sur mes projets, envoie un email hebdomadaire de résumé. C’est utile. Mais c’est un résumé de haut niveau : les erreurs les plus fréquentes, leur nombre d’occurrences, leur première apparition. Pas vraiment de quoi prendre une décision éclairée sur ce qui mérite une correction prioritaire.

Pour vraiment comprendre une erreur Sentry, il faut aller dedans : lire la stack trace, regarder quand elle a commencé à apparaître, comprendre combien d’utilisateurs sont touchés, croiser avec le code source pour identifier la cause probable. C’est un travail de titan quand on a plusieurs erreurs à traiter sur plusieurs projets.

L’accumulation silencieuse

Le vrai problème, ce n’est pas l’erreur isolée. C’est l’accumulation progressive d’erreurs non traitées qui finit par peser sur la qualité du produit et la confiance des utilisateurs. On ne les traite pas parce que c’est long, parce qu’on ne sait pas par où commencer, parce qu’il n’y a pas de processus clair.

J’avais besoin d’un processus automatisé qui transforme la surveillance des erreurs en actions concrètes dans GitHub.

Partie 2 — Ce que fait l’agent BB-LOG

Un audit hebdomadaire profond des erreurs Sentry

L’agent BB-LOG tourne une fois par semaine. Sa mission : passer en revue toutes les erreurs actives dans Sentry, les analyser en profondeur, et produire un rapport actionnable.

Ce n’est pas une simple copie du résumé Sentry. L’agent effectue une analyse réelle :

Critère d’analyse	Ce que l’agent évalue
Fréquence	Nombre d’occurrences sur la période
Impact utilisateur	Nombre d’utilisateurs distincts touchés
Gravité	Blocage complet, dégradation, ou comportement inattendu ?
Évolution	L’erreur est-elle nouvelle, en hausse, stable ou en baisse ?
Récidive	A-t-elle déjà été signalée dans une session précédente ?

Pour chaque erreur significative, l’agent va plus loin que les métadonnées Sentry. Il lit la stack trace, retrouve le fichier source concerné, et produit une pré-analyse des causes possibles.

La connexion MCP Sentry

L’accès à Sentry se fait via le protocole MCP (Model Context Protocol). Cela permet à l’agent de fouiller les issues Sentry en profondeur : lire les breadcrumbs, accéder aux détails de l’environnement au moment de l’erreur, voir les sessions utilisateurs affectées, naviguer dans l’historique d’une issue.

C’est cette profondeur d’accès qui fait la différence. L’agent ne lit pas un résumé — il explore, exactement comme un développeur qui irait manuellement faire le tour des erreurs.

Partie 3 — Du rapport Sentry aux tickets GitHub

Un CRON et Claude Code en mode CLI

L’agent BB-LOG est appelé via une tache CRON, que j’ai programmée chaque semaine. Ensuite, j’utilise Claude Code en mode CLI avec le mode autonome activé. Cela me permet d’utiliser mon forfait Claude directement — pas besoin de tokens API supplémentaires.

Un rapport docx structuré

Le premier livrable de l’agent, c’est un rapport au format docx. Pourquoi docx plutôt qu’un simple texte ? Parce que ce rapport est destiné à être partagé — avec un client, avec l’équipe, en réunion. Un document structuré avec une mise en page claire est bien plus efficace qu’un dump de terminal.

Le rapport inclut pour chaque erreur :

Un résumé de l’erreur en langage clair
Le contexte technique (fichier, fonction, ligne)
L’impact estimé (fréquence, utilisateurs touchés)
La ou les causes probables identifiées par l’analyse du code
La recommandation de traitement

La création automatique de tickets GitHub

Le rapport, c’est la vision. Les tickets, c’est l’action. Après avoir produit le rapport, l’agent crée dans GitHub un ticket pour chaque erreur qui mérite un correctif.

Ce n’est pas une création mécanique. L’agent :

Vérifie si le ticket existe déjà — si l’erreur a déjà été remontée la semaine précédente et que le ticket n’a pas été traité, il met à jour le ticket existant plutôt que d’en créer un doublon.
Rédige un titre clair — pas le message d’erreur brut, mais une description compréhensible de ce qui se passe.
Documente le ticket — description, contexte, lien vers l’issue Sentry, pré-analyse des causes, suggestion de correction.
Place le ticket en backlog — les tickets créés arrivent en backlog, pas directement dans le sprint.

La boucle avec l’agent BB-DEV

Une fois les tickets créés par BB-LOG, c’est moi qui décide lesquels méritent d’être traités en priorité. Si le correctif me semble simple et bien balisé, je le tague BB-DEV — et l’agent de développement BB-DEV s’en charge dès qu’il le peut.

Les agents travaillent ensemble. BB-LOG détecte et documente, BB-DEV corrige. Je reste le point de décision entre les deux.

Partie 4 — Ce que ça change sur la gestion des erreurs

Passer de la réaction à la prévention

Avant l’agent BB-LOG, je traitais les erreurs de manière réactive : quand un utilisateur signalait un problème, ou quand je tombais par hasard sur quelque chose dans Sentry. La couverture était partielle, le délai de traitement variable.

Avec BB-LOG, le cycle est devenu proactif. Chaque semaine, j’ai une vue complète des problèmes actifs, classée par impact. Je ne découvre plus un bug critique deux semaines après son apparition.

Un rapport bien plus riche que l’email Sentry

L’email hebdomadaire de Sentry vous dit qu’il y a 47 occurrences d’une erreur TypeError: cannot read property 'id' of undefined. L’agent BB-LOG vous dit que cette erreur touche 23 utilisateurs distincts depuis mardi, qu’elle se produit dans la fonction processOrder du fichier orders.service.ts à la ligne 142, que la cause probable est un cas non géré quand la commande n’a pas encore de ligne de produit, et que la correction probable est un guard de 3 lignes avant l’accès à la propriété.

Ce n’est pas la même information. C’est la différence entre une alerte et une analyse.

L’investissement en temps

Un audit hebdomadaire manuel des erreurs Sentry sur plusieurs projets prendrait facilement 2 à 3 heures. C’est du temps de développeur senior utilisé à une tâche de collecte et de mise en forme. Avec BB-LOG, ces 2 à 3 heures se passent sans moi. Ce que je reçois, c’est directement la synthèse sur laquelle je peux décider.

Vous voulez passer d’un monitoring passif à un traitement actif des erreurs ?

Chez Citios, j’aide les équipes à mettre en place des dispositifs de surveillance et de traitement automatisé : intégration Sentry, création de tickets, workflows de correction. Des systèmes qui font avancer la qualité sans attendre un incident critique.

Prendre contact — Sébastien Quéré, CTO à la demande

Mon premier agent BB-DEV — Quand l'IA fait le développement à ma place

Sébastien Quéré — Mon, 08 Jun 2026 00:00:00 GMT

Partie 1 — Pourquoi j’ai eu besoin d’un agent de développement

L’IA m’a rendu plus rapide, et pourtant

Depuis un peu plus d’un an, j’utilise Cursor intensivement pour mes développements. L’outil est devenu central dans ma façon de travailler : aujourd’hui, je travaille à 95 % assisté par des IA.

Au début, les résultats étaient inégaux. Une fois sur deux, le code produit ne compilait même pas. Mais les progrès ont été fulgurants. Les modèles de langage ont atteint un niveau où ils livrent du code de qualité correcte de manière régulière, y compris sur des tâches complexes.

Et c’est là qu’est apparu un nouveau problème.

Plus l’IA est capable, plus je lui confie de travail. Et plus je lui confie de travail, plus je me retrouve à… attendre. J’essayais de jongler entre plusieurs projets ou plusieurs features en parallèle pour rester productif pendant qu’elle travaillait. Mais ce n’est pas très efficace : chaque changement de contexte a un coût cognitif. Et sur les tâches simples, je perdais clairement du temps à rester impliqué dans des cycles qui pourraient se dérouler sans moi.

Le constat : certaines tâches n’ont pas besoin de moi

Il y a des tickets où le travail est clair, balisé, sans ambiguïté. Un correctif de bug documenté. Une nouvelle page qui suit un pattern existant. Une intégration d’API bien spécifiée. Ce type de tâche ne demande pas de décision architecturale, pas de négociation avec le client, pas d’arbitrage technique. Il demande juste de l’exécution.

C’est exactement là que je perdais du temps : à rester dans la boucle pour des choses qui n’ont pas besoin que je sois dans la boucle.

Ma conclusion : il me fallait un agent capable de prendre en charge ces tickets de bout en bout — de la récupération du ticket jusqu’au pull request — sans que j’aie à intervenir.

Partie 2 — Ce qui n’a pas marché

Les échecs, ça forme aussi

Si tout avait marché du premier coup, cet article serait beaucoup moins intéressant à écrire — et probablement aussi à lire. Je trouve qu’on apprend autant de ses réussites que de ses échecs. C’est pour ça que je tiens à partager ce qui n’a pas fonctionné pour moi avant d’arriver à BB-DEV. Spoiler : ça a pris plusieurs détours.

OpenClaw

Premier essai : OpenClaw, sur un vieux PC Ubuntu que j’avais sous la main. Installation complexe, plusieurs heures à batailler, et au bout du compte des instabilités qui refusaient de disparaître. J’ai fini par lâcher l’affaire. Parfois, le bon réflexe, c’est de savoir s’arrêter avant d’y laisser sa soirée.

Hermes Agent

Deuxième tentative : Hermes Agent, cette fois sur un VPS chez Hostinger. L’installation est plus simple — Hostinger propose une image “toute prête” — mais même avec ça, j’ai eu droit à des instabilités entre le front et la gateway. Mon Claude Code m’a bien aidé à creuser les problèmes (oui, j’utilise déjà l’IA pour configurer mes IA, on n’arrête pas le progrès), mais la gateway de Hermes continuait de redémarrer toute seule. Je ne suis pas administrateur système, mais disons que c’était quand même bien technique pour ce que je voulais en faire.

Une fois le système stabilisé, j’ai commencé à utiliser Hermes pour configurer un premier agent. J’ai acheté pour 10 € de tokens chez Anthropic. Résultat : une dizaine de prompts plus tard — pour configurer l’agent, créer une première skill et connecter un MCP — les 10 € étaient déjà cramés. Autant dire que ça ne m’a pas franchement rassuré sur l’efficience de la consommation de tokens.

Google ADK et OpenHands

J’ai aussi creusé du côté de Google Agent Development Kit (ADK) : très puissant, mais largement surdimensionné pour mon besoin. Et OpenHands, qui m’a semblé être une très bonne solution sur le papier — mais qui, comme Hermes, fait également tourner la note en consommant des tokens d’API.

La conclusion qui s’est imposée

Tous ces essais m’ont amené à la même conclusion : il me fallait un petit script maison, capable de s’appuyer sur les abonnements que je paie déjà — Claude Code et Cursor — plutôt que de cramer des tokens d’API à chaque interaction. C’est cette idée toute simple qui a posé les bases de ce qui allait devenir BB-DEV.

Partie 3 — Architecture de l’agent BB-DEV

Les composants du système

L’agent BB-DEV repose sur un ensemble de briques simples, délibérément légères :

Composant	Rôle
VPS Hostinger	Environnement d’exécution stable et toujours disponible
Liste de projets GitHub + tokens	Périmètre d’action défini manuellement
Script Python de récupération des tickets	Filtre et sélectionne les tâches éligibles
Claude Code en mode CLI	Exécute le développement de manière autonome
Les skills du projets	Indiquent à Claude comment travailler sur ce projet
Le MCP GitHub	Permet d’interagir avec le repo et les issues
Cron toutes les heures	Orchestre le cycle complet

Pourquoi un script Python pour la collecte, pas une IA ?

C’est un choix délibéré. La collecte des tickets GitHub est une opération simple et déterministe : appeler l’API GitHub, filtrer sur un tag spécifique (BB-DEV), retourner la liste. Faire passer cette étape par une IA aurait consommé des tokens inutilement sur une opération qui n’a pas besoin d’intelligence.

La règle que j’applique : l’IA intervient là où l’intelligence est nécessaire, pas là où la logique suffit.

Le filtre `BB-DEV` : comment je décide ce que l’agent peut traiter

Je ne confie pas tous les tickets à l’agent. Seulement ceux que j’ai volontairement tagués BB-DEV. C’est moi qui fais l’aiguillage. Ce tag signifie : “j’ai évalué ce ticket, le développement est suffisamment clair et borné pour que l’agent s’en charge sans mon intervention.”

Ce mécanisme me donne deux garanties :

L’agent ne travaille jamais sur quelque chose d’ambigu ou de risqué sans que je l’aie décidé.
Je garde la main sur la stratégie et les arbitrages techniques.

Claude Code en mode CLI : le cœur de l’exécution

Pour l’exécution du développement, j’utilise Claude Code en mode CLI avec le mode autonome activé. Cela me permet d’utiliser mon forfait Claude directement — pas besoin de tokens API supplémentaires.

Le modèle utilisé est Claude Sonnet. C’est un bon équilibre entre performance et coût pour des tâches de développement courantes.

Un point important : toute la configuration du projet — contexte, skills, MCPs — est versionnée dans le dépôt. Claude Code la charge automatiquement quand il démarre sur un projet. Il n’y a donc aucune configuration supplémentaire à faire côté agent : le comportement attendu de l’IA est décrit dans le projet lui-même.

Partie 4 — Le cycle de vie d’un ticket

De l’issue GitHub au pull request

Voici ce qui se passe à chaque exécution du cron :

1. Le script Python interroge l'API GitHub
   └── pour chaque projet dans la liste
       └── récupère les tickets ouverts avec le tag "BB-DEV"

2. Pour chaque ticket éligible
   └── Lance Claude Code en mode autonome
       ├── avec le contexte du ticket
       ├── dans le dossier du projet concerné
       └── avec les instructions pour créer une branche, développer, committer et ouvrir un PR

3. Claude Code exécute le développement
   ├── analyse le code existant
   ├── implémente les modifications
   ├── teste ce qui peut l'être
   └── crée le pull request

4. Le ticket est mis à jour sur GitHub

Ce que l’agent fait seul

Depuis un mois que le système tourne, l’agent a traité 25 tickets sans intervention de ma part. Ce sont principalement :

Des petits correctifs de bugs avec une cause identifiée
Des ajouts de features simples qui suivent des patterns existants
Des mises à jour de contenu ou de configuration
Un ticket par jour, pas si mal

Ce que je continue de faire moi-même

L’agent ne remplace pas le jugement. Je continue de traiter :

Les tickets qui nécessitent un échange avec le client
Les choix d’architecture ou de modèle de données
Les features nouvelles sans pattern existant dans le projet
Tout ce qui touche à la sécurité ou aux données sensibles

La ligne de partage est claire : exécution déléguée, décision gardée.

Partie 5 — Ce que ça change concrètement

La fin du coût de réentrée sur les petites tâches

Avant, même pour un ticket simple, je devais ouvrir le projet, retrouver le contexte, lancer l’IA, relire le code produit, committer. Sur un ticket qui prend 20 minutes d’exécution, le coût de ma présence était réel.

Maintenant, ces tickets se traitent sans moi, dans la journée, au fil du cron. Quand je reviens sur le projet, le PR est là, je le relis, je le merge ou je demande une correction.

Un rythme de développement en arrière-plan

Le système s’étale dans la journée : maximum un ticket par heure par le cron. Cela crée un flux régulier de small PRs qui avancent les projets de manière continue, sans que je sois présent.

Je n’ai pas encore eu de saturation du forfait Claude, même en travaillant en parallèle sur plusieurs projets.

Ce que je veux faire évoluer

Le système actuel est volontairement simple. Pour la suite, j’explore l’idée de remplacer mes scripts maison par un SDK dédié comme OpenHands, qui offre une abstraction plus robuste pour ce type d’orchestration multi-agents.

Je vais également essayer Hermes Agent avec un compte Open AI qui me permettra d’utiliser le forfait fourni par Open AI, mais sous la forme d’API, ce que ne permet plus Claude.

Enfin et surtout, je vais continuer de créer de nouveaux agents. BB-DEV a besoin d’être bien entouré pour constuire une équipe de choc. Je vous tiens au courant dans les prochaines semaines.

Chez Citios, j’accompagne les équipes tech et les fondateurs dans l’automatisation de leurs workflows de développement. Définir le périmètre d’action, choisir les outils, sécuriser le processus : c’est le genre de cadrage qui évite de partir dans une mauvaise direction.

Comment protéger chaque client de ses voisins

Sébastien Quéré — Thu, 30 Apr 2026 00:00:00 GMT

Partie 1 — Le problème que tout fondateur SaaS doit comprendre

L’incident qui ne devrait jamais arriver

Imaginez la scène : Thomas dirige une PME, il utilise votre logiciel SaaS depuis six mois. Un matin, il se connecte à son tableau de bord et tombe sur une liste de contacts qui ne lui appartient pas — les prospects d’un concurrent direct, stockés dans le même outil que lui. Il vous appelle, furieux. Vous cherchez dans votre code. Vous trouvez : un filtre oublié, une ligne manquante dans une requête. Rien de malveillant. Juste une erreur humaine. Mais la confiance, elle, est déjà brisée.

Ce scénario n’est pas rare. Il arrive quand on construit un SaaS sans réfléchir dès le départ à l’isolation des données entre les clients.

Plusieurs clients, une seule base de données : le défi du multi-tenancy

Un SaaS, par définition, sert plusieurs clients — on les appelle des tenants (locataires, en anglais). Ils partagent la même application, les mêmes serveurs, parfois la même base de données. C’est ce qui rend le modèle économiquement viable : mutualiser les coûts d’infrastructure.

Un SaaS, c’est donc comme une sorte de colocation. Il y a des parties accessibles à l’ensemble des locataires, comme le hall d’entrée, les ascenseurs, mais il y a également des parties privées qu’il faut absolument sécuriser. Comment s’assurer que les données du client A ne sont jamais accessibles au client B ?

Il existe trois grandes approches pour répondre à cette question :

Approche	Principe	Coût	Sécurité	Complexité
Une base par client	Chaque client a sa propre base de données isolée	Élevé	Maximale	Forte (déploiement, maintenance)
Un schéma par client	Même base, mais des espaces séparés à l’intérieur	Moyen	Bonne	Moyenne
Même table, filtre par ID client	Toutes les données cohabitent, séparées par un identifiant	Faible	Variable	Faible… mais risquée

La troisième approche — toutes les données dans les mêmes tables, triées par un identifiant client — est la plus répandue dans les SaaS modernes. Elle est moins coûteuse, plus simple à maintenir, et suffit amplement si elle est bien sécurisée. C’est elle que font tourner la majorité des outils que vous utilisez au quotidien.

Le risque caché : la sécurité dans le code, ça se casse

Avec cette approche, chaque requête vers la base de données doit inclure un filtre du type : “donne-moi uniquement les projets appartenant à ce client”. Ce filtre, c’est le développeur qui l’écrit, à la main, dans chaque requête.

Le problème ? Un développeur distrait, fatigué, ou simplement pressé, peut oublier ce filtre. Une fois. Sur une seule requête. Et c’est suffisant pour exposer les données d’un client à un autre.

La sécurité placée uniquement dans le code applicatif est fragile. Elle dépend de la rigueur humaine. Ce qu’il faut, c’est un filet de sécurité plus bas : au niveau de la base de données elle-même.

Partie 2 — Ce que Supabase apporte : RLS, le garde-fou dans la base

Supabase en trois lignes

Supabase est une plateforme open source qui fournit une base de données PostgreSQL managée, une API générée automatiquement, un système d’authentification, et des outils de stockage de fichiers. C’est l’un des choix les plus populaires pour construire un SaaS moderne rapidement, sans gérer soi-même l’infrastructure. Je l’utilise dans de nombreux projets.

Ce qui nous intéresse ici, c’est une fonctionnalité native de PostgreSQL qu’il expose facilement : la Row Level Security.

Row Level Security : la base qui se défend elle-même

La Row Level Security (RLS) — ou Sécurité au Niveau des Lignes — est un mécanisme qui permet de définir des règles directement dans la base de données pour contrôler qui peut lire ou modifier quelles lignes.

Concrètement : même si un développeur oublie un filtre dans son code, la base de données refusera de renvoyer des lignes qui n’appartiennent pas à l’utilisateur connecté. La base devient son propre garde-fou.

Analogie : imaginez un immeuble de bureaux où chaque locataire a son propre couloir avec une serrure. Peu importe qui tient la clé de l’immeuble ou qui ouvre la porte principale — sans la bonne clé de couloir, personne n’entre. Ce n’est pas le gardien qui protège les couloirs (il peut se tromper, être absent), c’est la serrure elle-même.

Pourquoi c’est supérieur à un filtre dans le code

	Filtre dans le code	Row Level Security
Où se trouve la protection	Dans l’application	Dans la base de données
Risque d’oubli	Oui, à chaque requête	Non, s’applique automatiquement
Applicable à tous les accès	Non (APIs externes, scripts…)	Oui, quel que soit l’appelant
Confiance nécessaire	Dans chaque développeur	Dans la configuration initiale

Premiers éléments de code

Activer RLS sur une table se fait très simplement avec l’interface Supabase. Pour l’activer sur une table, en ligne de commande SQL :

-- On active le verrou sur la table "projects"
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

À partir de là, si vous réalisez une requête SELECT * FROM projects, même sans aucun filtre, la base ne renverra aucune ligne. C’est le principe du security by design. Par défaut, vous ne voyez aucune donnée et vous ne pouvez pas non plus les modifier. Pour voir des données, nous allons devoir ajouter des Policies.

Partie 3 — Mise en œuvre concrète : du modèle de données à la politique

B2B ou B2C : comment segmenter ?

La question de l’isolation des données ne se pose pas de la même façon selon votre modèle :

B2C (vous vendez à des particuliers) : chaque utilisateur est son propre tenant. L’identifiant de l’utilisateur suffit comme clé d’isolation. C’est simple.
B2B (vous vendez à des entreprises, avec plusieurs utilisateurs par client) : un tenant = une organisation. Plusieurs utilisateurs partagent les données de leur entreprise, mais pas celles des autres. C’est le cas le plus courant et le plus structurant.

Dans un contexte B2B, il faut une table intermédiaire qui relie chaque utilisateur à son organisation. C’est cette organisation — et non l’utilisateur — qui devient l’unité d’isolation.

Modèle de données type

Chaque table métier doit porter un champ organisation_id (ou tenant_id) qui fait le lien avec le propriétaire de la donnée.

┌─────────────────┐       ┌───────────────────┐       ┌───────────────────┐
│ organisations   │       │ members           │       │ projects          │
│─────────────────│       │───────────────────│       │───────────────────│
│ id              │◄──┐   │ id                │   ┌──►│ id                │
│ name            │   └───│ organisation_id   │   │   │ name              │
│ created_at      │       │ user_id           │   │   │ organisation_id   │
└─────────────────┘       │ role              │   │   │ created_at        │
                          └───────────────────┘   │   └───────────────────┘
                                                  │
                          ┌───────────────────┐   │
                          │ tasks             │   │
                          │───────────────────│   │
                          │ id                │   │
                          │ project_id        │───┘
                          │ organisation_id   │──►(filtre RLS)
                          └───────────────────┘

Règle d’or : toute table qui contient des données métier sensibles doit avoir un organisation_id. Sans ça, RLS ne peut pas s’appliquer.

Gestion des rôles : qui voit quoi ?

Dans un SaaS B2B, il y a généralement trois niveaux d’accès :

Utilisateur standard : voit uniquement les données de son organisation
Admin organisation : voit toutes les données de son organisation, peut gérer les membres
Super-admin SaaS (vous) : accès technique global, jamais exposé côté client

Pour implémenter cela, on utilise une fonction sécurisée qui récupère l’organisation de l’utilisateur connecté, puis on base les politiques RLS dessus :

-- Fonction sécurisée : récupère l'organisation de l'utilisateur connecté
CREATE OR REPLACE FUNCTION private.get_user_organisation_id()
RETURNS bigint
LANGUAGE sql
SECURITY DEFINER
SET search_path = private
AS $$
  SELECT organisation_id
  FROM public.members
  WHERE user_id = auth.uid()
  LIMIT 1;
$$;
REVOKE ALL ON FUNCTION private.get_user_organisation_id() FROM public;
GRANT EXECUTE ON FUNCTION private.get_user_organisation_id() TO authenticated;

Ensuite, pour chaque table métier, nous allons devoir ajouter une politique RLS. Par exemple, pour la table “members” :

-- Politique : un utilisateur voit uniquement les membres de son organisation
CREATE POLICY "Select members for authenticated"
on "public"."members"
to authenticated
FOR SELECT
USING (
  organisation_id = private.get_user_organisation_id()
);

Et voici comment gérer un usage admin :

-- Fonction pour récupérer l'organisation pour laquelle l'utilisateur est admin
CREATE OR REPLACE FUNCTION private.get_admin_organisation_id()
RETURNS bigint
LANGUAGE sql
SECURITY DEFINER
SET search_path = private
AS $$
  SELECT organisation_id
  FROM public.members
  WHERE user_id = auth.uid() and role = 'admin'
  LIMIT 1;
$$;
REVOKE ALL ON FUNCTION private.get_admin_organisation_id() FROM public;
GRANT EXECUTE ON FUNCTION private.get_admin_organisation_id() TO authenticated;

Ensuite, pour mettre à jour la table “members” avec le rôle admin :

-- Politique : Seul l'admin peut modifier un membre de son organisation
CREATE POLICY "Update members for admin authenticated"
on "public"."members"
to authenticated
FOR UPDATE
USING (
  organisation_id = private.get_admin_organisation_id()
)
WITH CHECK (
  organisation_id = private.get_admin_organisation_id()
);

Notez bien que ces fonctions ont été créées sur un schéma indépendant appelé ici private. Vous devrez bien sûr adapter ces fonctions à votre modèle de données.

Pièges courants à éviter

1. Oublier une table. RLS doit être activé sur toutes les tables métier. Une seule table sans protection suffit à créer une fuite. Tenez une checklist lors de chaque migration. Supabase vous alerte (dans les règles de sécurité) si vous n’avez pas activé RLS sur toutes les tables.

2. Les jointures qui contournent. Si une table A est protégée mais qu’elle joint une table B non protégée, les données de B peuvent fuir via la jointure. RLS s’applique table par table — pensez à l’activation de bout en bout.

3. Les migrations non testées. Ajouter une colonne, renommer une table, créer une vue — tout cela peut interagir avec les politiques existantes. Testez les accès après chaque migration en base.

4. Le super-admin dans le code. Ne codez jamais un bypass de RLS dans votre application. L’accès super-admin doit passer par des connexions techniques séparées, jamais par un utilisateur applicatif.

Partie 4 — Ce que ça change pour votre produit (et vos clients)

Sécurité by design vs. sécurité ajoutée après

Il y a deux façons de gérer la sécurité dans un produit :

La sécurité rajoutée : on construit vite, on sécurise plus tard. C’est tentant au démarrage. C’est risqué à long terme — les couches de sécurité s’ajoutent en patchwork sur une architecture qui n’y était pas préparée.
La sécurité by design : on intègre les contraintes dès la conception. Ça prend un peu plus de temps au départ. Ça évite des incidents coûteux, des refactorisations lourdes, et des clients perdus.

RLS, c’est de la sécurité by design. Elle ne se greffe pas sur une architecture existante — elle est l’architecture. La mettre en place dès le premier sprint, c’est un investissement qui rapporte à chaque nouvelle table ajoutée. En réalité, une fois que vous avez créé les quelques fonctions SQL nécessaires, cela devient un réflexe et le temps passé sur chaque nouvelle table devient négligeable.

Ce que vous pouvez dire à vos clients

Avec RLS correctement configuré, vous pouvez tenir ce discours à vos clients en toute honnêteté :

“Vos données sont protégées au niveau de la base de données elle-même. Même en cas d’erreur dans notre code, un compte client ne peut pas accéder aux données d’un autre client.”

C’est un argument de confiance fort, surtout face à des acheteurs B2B qui posent des questions sur la sécurité lors des demos ou lors de revues de conformité.

Conformité RGPD : RLS comme levier d’isolation

Le RGPD impose de garantir que les données personnelles de vos clients sont traitées et stockées de façon sécurisée. L’isolation par RLS contribue directement à deux principes clés :

La minimisation des accès : chaque utilisateur ne voit que ce dont il a besoin
La séparation des données : les données d’un client ne peuvent pas être atteintes par un autre

Ce n’est pas suffisant seul — la conformité RGPD est plus large — mais c’est une brique solide à documenter dans votre politique de sécurité et à mentionner dans vos CGV ou DPA (Data Processing Agreement).

Les limites à connaître

RLS est puissant, mais ce n’est pas une solution totale. Il ne remplace pas :

Le chiffrement des données sensibles (mots de passe, données bancaires, données médicales)
Les logs d’audit pour tracer qui a accédé à quoi et quand
Les sauvegardes isolées par client, utiles en cas de demande RGPD de suppression ou de portabilité
Les tests de pénétration réguliers pour vérifier l’ensemble de la chaîne

Une bonne architecture SaaS combine plusieurs couches. RLS en est une — essentielle, mais non exclusive.

Chez Citios, j’accompagne les fondateurs et équipes tech dans la conception d’architectures SaaS robustes : choix de stack, modèle de données, sécurité by design, audit de base existante. Que vous partiez de zéro ou que vous vouliez sécuriser un produit existant, une heure de cadrage peut éviter des mois de dette technique.

Comment cadrer un MVP sans brûler son budget tech

Sébastien Quéré — Tue, 13 Jan 2026 00:00:00 GMT

La plupart des startups et PME ne ratent pas leur MVP par manque de compétences techniques. Elles le ratent parce qu’elles ont mal cadré le périmètre au départ — et que personne n’a tenu ce périmètre sous pression.

Voici une méthodologie en 6 étapes que j’applique avec mes clients pour aligner business, produit et engineering sans multiplier les sprints inutiles.

1. Définir le périmètre minimal

La question à se poser : “Quel est le strict minimum pour valider mon hypothèse de valeur ?”

Pas le minimum confortable. Le strict minimum.

Parfois, une landing page suffit. Avec les outils disponibles aujourd’hui, vous pouvez avoir un mini-site en ligne en une journée. Ce n’est pas le MVP, mais c’est un signal précoce : est-ce que des gens cliquent ? Est-ce que quelqu’un laisse son email ?

L’objectif du MVP, c’est de prouver que vous résolvez un vrai problème pour de vrais utilisateurs — et d’identifier ceux pour qui ce problème est le plus urgent. Lean Startup d’Eric Ries reste la meilleure référence sur ce sujet.

2. Prioriser avec l’équipe (et pas seul dans un coin)

La priorisation n’est pas un exercice solitaire. Impliquez product, tech et business dans une session de travail dédiée — 2h maximum, avec un livrable clair en sortie : une liste ordonnée des fonctionnalités candidates, avec une décision explicite sur ce qui est in, ce qui est out, et ce qui est plus tard.

Deux formats qui marchent bien :

RICE ou Value vs Effort : objectiver les décisions avec des scores, évite les débats d’opinion
Buy-a-feature : chaque participant dispose d’un budget fictif à répartir entre les fonctionnalités. La somme des votes révèle les vraies priorités collectives — et souvent surprend tout le monde

Ce type d’atelier a un effet secondaire précieux : il crée un engagement partagé sur le périmètre. Quand quelqu’un demande d’ajouter une feature plus tard, vous pouvez revenir à cette décision collective.

3. Tenir le périmètre face aux pressions — le vrai défi

C’est là que la plupart des MVP déraillent. Pas à cause d’un bug technique. À cause d’une demande du cofondateur à J+10 : “Juste une petite chose, ça prend deux jours max.”

J’ai observé ce pattern dans des équipes de toutes tailles. La pression vient souvent des meilleures intentions — un client important a fait une demande, un investisseur a posé une question, une démo approche.

La discipline de périmètre, ça se tient collectivement :

Nommez un décideur unique sur le périmètre MVP (CTO, CPO, ou CEO — mais une seule personne)
Toute nouvelle demande passe par l’atelier de priorisation — elle déplace quelque chose, ou elle attend la v2
Rendez visible le coût d’un ajout : “Cette feature, c’est 3 jours de dev, soit 2 semaines de décalage sur le lancement”

La transparence sur le coût réel est le meilleur rempart contre le feature creep.

4. Estimer le budget réel — coûts visibles et invisibles

Les estimations de développement sont rarement fausses sur les fonctionnalités elles-mêmes. Elles oublient le reste.

Ce qu’on oublie souvent :

Infra et hébergement (même minimal, ça se configure)
Authentification, gestion des rôles, sécurité de base
Tests, intégration continue, déploiement
Onboarding des premiers utilisateurs (support, bugs, itérations rapides)
Maintenance corrective post-lancement

Ma règle pratique : si vous n’êtes pas habitué à estimer, multipliez par 1,5 les estimations de votre équipe. Pas par pessimisme — par réalisme.

L’autre approche que je recommande : le Poker Planning avec l’équipe de dev. C’est plus lent qu’une estimation solo, mais l’engagement et la responsabilisation qui en découlent valent largement le temps investi.

Si le total vous semble déraisonnable, le problème est en amont : le périmètre n’est pas assez sélectif. Retour à l’étape 2.

5. Prototyper — et savoir quand arrêter

Ne développez pas ce que vous pouvez prototyper. Les outils actuels (Bolt, Lovable, Figma, Framer, etc.) permettent d’avoir quelque chose de cliquable en quelques heures.

Un prototype bien fait vous permet :

De valider l’UX avant d’investir du temps de dev
De challenger vos estimations (souvent à la baisse)
D’obtenir des feedbacks concrets d’utilisateurs — pas des opinions sur un document Word

Mais attention à la limite : un prototype n’est pas scalable. Le moment de basculer vers du vrai code, c’est quand vous avez validé les parcours critiques et que vous avez vos premiers utilisateurs prêts. Pas avant — pas après non plus.

Garder un prototype trop longtemps est un piège : ça crée une fausse sensation d’avancement et accumule de la dette implicite si le prototype devient “temporairement” le produit.

6. Lancer, apprendre, itérer

“Si tu n’as pas honte de la première version de ton produit, c’est que tu as lancé trop tard.” — Reid Hoffman

L’objectif du MVP n’est pas la perfection. C’est l’apprentissage le plus rapide possible.

Et n’attendez pas le lancement pour parler de votre produit. Chaque conversation avec un utilisateur potentiel avant le lancement est un feedback gratuit que vous n’avez pas à payer en sprints de développement.

En résumé

Le MVP ne brûle pas le budget à cause de mauvais devs ou de mauvais outils. Il le brûle quand :

le périmètre n’est pas décidé collectivement
personne ne le défend sous pression
les coûts invisibles ne sont pas anticipés
le prototype dure trop longtemps

C’est exactement le rôle d’un CTO fractionné : tenir ce cadre, même quand c’est inconfortable, pour que l’équipe avance vite sur ce qui compte.

Pourquoi j'ai créé une activité de CTO à la demande

Sébastien Quéré — Tue, 25 Nov 2025 00:00:00 GMT

Après 25 ans dans la tech — d’abord comme directeur produit pendant 15 ans, puis comme directeur technique sur des équipes jusqu’à 47 personnes — j’ai pris une décision qui m’a semblé évidente : devenir CTO freelance.

Pas par envie de liberté abstraite. Par conviction que le vrai problème à résoudre est ailleurs.

Le problème que j’observe depuis des années

Les startups et PME innovantes ont deux modes de fonctionnement quand elles ont besoin d’expertise tech :

Mode 1 : elles recrutent un CTO. C’est long (3 à 6 mois en moyenne), coûteux, et risqué — surtout en early stage, quand le produit n’est pas encore stabilisé et que les besoins changent vite. Un mauvais recrutement à ce stade peut coûter 12 à 18 mois de retard.

Mode 2 : elles font sans. Le fondateur technique prend tout sur lui, ou l’équipe avance sans cap clair. On accumule de la dette technique, on prend des décisions d’architecture par défaut, on recrute sans critères précis. Les problèmes se révèlent 18 mois plus tard, quand ils sont beaucoup plus chers à corriger.

Il existe un troisième chemin. C’est ce que j’ai construit avec Citios.

Ce qu’est Citios

Citios, c’est un CTO expérimenté disponible à la demande — sans les contraintes d’un recrutement, sans engagement long terme, avec un niveau d’expertise immédiatement opérationnel.

J’interviens sur trois dimensions :

La tech. Architecture, choix de stack, audit de code, scalabilité, développement de MVP, outillage interne. Les décisions techniques structurantes que l’équipe n’a pas le recul ou le temps de prendre seule.

Le management. Méthodes de travail, structuration d’équipe, recrutement, pilotage du delivery, montée en compétences. Une équipe technique bien organisée va deux fois plus vite — c’est mesurable.

Le produit. Roadmap, priorisation, arbitrages entre vitesse et qualité, alignement business-tech. Le CTO ne fait pas que de la technique : il traduit la vision produit en décisions d’architecture, et il défend les contraintes techniques face aux attentes business.

Comment ça fonctionne concrètement

Une journée, une semaine ou plusieurs mois : je m’adapte à la situation réelle, pas à un forfait prédéfini.

Certains clients ont besoin d’un regard externe ponctuel — un audit, un recrutement à cadrer, une décision d’architecture à trancher. D’autres ont besoin d’une présence régulière sur la durée, le temps de structurer l’équipe et d’installer les bonnes pratiques.

Dans tous les cas, l’objectif est le même : avancer vite sur ce qui compte, sans accumuler les problèmes pour plus tard.

Pourquoi maintenant

La fenêtre entre “l’idée existe” et “le produit est prêt à scaler” est courte. C’est là que les décisions structurantes se prennent — et qu’elles ont le plus d’impact sur la suite.

Un CTO senior qui arrive au bon moment peut faire gagner 6 à 12 mois sur le time-to-market, éviter une refonte technique coûteuse, et poser les bases d’une organisation qui tient dans la durée.

C’est le service que j’ai voulu rendre accessible, sans les frictions d’un recrutement classique.

Citios est disponible dès maintenant pour des missions en Bretagne, à Paris, et à distance.

Blog Citios — Insights tech & produit

REX : une après-midi pour rendre le design de Citios Impeccable

C’est quoi Impeccable ? (et comment l’installer)

Installation (si tu bosses dans Cursor)

Le point de départ : un site qui « marche », pas un système

Acte 1 — Écrire avant de peindre

PRODUCT.md — le vrai du faux

DESIGN.md — la carte d’identité visuelle

Acte 2 — Le choc du premier audit

Acte 3 — Le problème du teal trop beau

Acte 4 — Une suite de passes, pas un bouton magique

Acte 5 — Amplifier une page, sans tout changer

Ce qui était mou

Le geste décisif

Ce qui a vraiment changé sur le site (concret)

Deux registres, une marque

Accessibilité sans théâtre

Plus léger, plus soigné

Copy & faits

Ce que j’ai appris sur le duo CTO + assistant design

1. Le brief gagne toujours

2. Le détecteur se trompe parfois

3. Les petits chantiers restants ne sont pas des échecs

4. Le design sert la conversation, pas l’ego

Pour qui ça vaut le coup de reproduire ?

Et maintenant ?

Le Harness en IA — Transformer un modèle brut en agent autonome et fiable

Partie 1 — Qu’est-ce qu’un harness ?

Plus qu’un wrapper autour d’un LLM

Pourquoi c’est indispensable

Partie 2 — Cas pratique : le harness de BB-DEV

La mission

Ce qui est déterministe, ce qui ne l’est pas

Le résultat

Partie 3 — Cas pratique : le harness de BB-LOG

La mission

La structure du harness

L’impact

Partie 4 — L’équilibre génératif / déterministe

La règle que j’applique

Ce que ça apporte concrètement

En résumé

Maîtriser l'API Gemini pour les architectures d'agents intelligents

Partie 1 — Fondations de l’API Gemini

Modèles et capacités

Authentification et environnement

Deux modes d’appel : streaming et JSON

Partie 2 — Ingénierie des prompts et output structuré

Le system prompt : plus qu’une persona

Contexte conversationnel

Output structuré : générer un ticket fiable

Partie 3 — Architecture des agents avec les Tools

Le principe

Déclaration des outils

La boucle d’agent : runToolAgentLoop

Normaliser les appels d’outils

Scénario concret : diagnostiquer un bug via GitHub

Partie 4 — Déploiement et bonnes pratiques

Serverless

Logging

Ce que je retients en production

En résumé

BB-PO — l'assistant IA qui répond à vos questions projet et rédige vos tickets

Partie 1 — Un assistant, pas un agent

La différence compte

Où il vit

Partie 2 — Ce que BB-PO sait faire

Répondre aux questions sur le projet

Créer un ticket d’évolution

Créer un ticket de bug

Partie 3 — Sous le capot

Le moteur IA : Gemini

Un niveau comparable à Claude Cowork, avec le board en plus

Partie 4 — Une nouvelle offre : ouvrir l’application aux clients

Pourquoi maintenant

Ce que ça change pour vous

Agent BB-LOG — Quand l'IA surveille les logs à ma place

Partie 1 — Le problème des erreurs en production

Les erreurs existent. La question c’est comment on les traite.

L’accumulation silencieuse

La boucle d’agent : `runToolAgentLoop`

Le filtre `BB-DEV` : comment je décide ce que l’agent peut traiter