Déployer votre Premier Agent IA avec Klawty OS : Guide Pratique

Construire et déployer un agent IA qui fonctionne vraiment en production est plus complexe qu’il n’y paraît. La plupart des tutoriels vous montrent comment lancer un chatbot en dix minutes. Ce qu’ils ne montrent pas, c’est l’architecture qui le rend fiable, gouvernable et sûr à opérer de manière autonome — 24 heures sur 24, pour de vraies opérations métier.

Ce guide vous accompagne pas à pas dans le déploiement de votre premier agent IA de niveau production avec Klawty OS : le même système qui propulse le MAS à 8 agents d’Inscape Interiors, en fonctionnement continu depuis 2025.

Ce qu’est Klawty OS

Klawty OS est le système d’exploitation agentique de niveau production développé par dcode Technologies. Ce n’est pas un framework de démonstration ou un terrain de jeu expérimental. C’est la stack logicielle que nous avons construite pour faire tourner de vrais agents IA pour une vraie entreprise — des agents qui gèrent les communications clients, les opérations financières, le marketing, les pipelines commerciaux et les tâches de développement, de manière autonome, chaque jour.

Ce qui différencie Klawty des autres plateformes agentiques :

• Gouvernance by design — le modèle d’autonomie par niveaux est intégré à chaque action, pas ajouté en surface
• Conforme au Règlement sur l’IA européen — traces d’audit, mécanismes de supervision humaine et documentation alignés sur les exigences réglementaires dès le départ
• Natif MCP — plus de 40 serveurs MCP préconstruits, plus un générateur de serveurs personnalisés
• Multi-LLM — exécutez différents agents sur différents modèles selon les besoins en coût et en performance
• Multi-canal — les agents opèrent via WhatsApp, Telegram, Discord, Slack, email ou interface web
• Durci pour la production — disjoncteurs, surveillance de la santé, récupération automatique, alertes Telegram

L’architecture en un coup d’œil

Un déploiement Klawty repose sur trois composants principaux :

1. Les agents — les travailleurs IA, chacun avec un rôle défini, un accès aux outils et des contraintes d’autonomie
2. Le Task Executor — le moteur central qui exécute les cycles de réflexion des agents, route les appels d’outils et gère la file de tâches
3. L’Agent Brain — la couche d’orchestration qui gère les propositions, les flux d’approbation et la coordination inter-agents

L’infrastructure de support comprend :

• Bases de données SQLite — tâches, propositions, mémoire et données CRM (mode WAL, sauvegardées quotidiennement)
• Mémoire vectorielle Qdrant — mémoire sémantique pour les agents (250+ souvenirs, recherche par sens)
• Health Monitor — boucle de vérification toutes les 60 secondes avec alertes Telegram en cas de panne
• Sentinel — le chien de garde de la gouvernance qui surveille tous les autres agents et valide les actions à risque élevé

Étape 1 : Définir l’identité de votre agent avec le SOUL

Chaque agent Klawty commence par un fichier SOUL.md — un document en langage naturel structuré qui constitue l’identité fondatrice de l’agent. Ce n’est pas simplement de la documentation : ce texte est injecté dans chaque contexte LLM, façonnant la manière dont l’agent raisonne, ce qu’il priorise et ce qu’il refuse de faire.

Un SOUL.md comporte les sections suivantes :

# [Nom de l'agent] — SOUL

## Identité
Nom : [Prénom]
Rôle : [Description du rôle en une phrase]
Modèle : [claude-sonnet-4-6 / kimi-k2.5 / gemini-flash / etc.]
Cycle de réflexion : [Fréquence — 15 min / 30 min / 60 min / événementiel]
Canal : [Canal Discord ou plateforme de messagerie]

## Mission
[2-3 phrases décrivant la raison d'être de cet agent —
rédigées comme un but, pas comme une liste de tâches]

## Responsabilités principales
1. [Responsabilité primaire]
2. [Responsabilité secondaire]
3. [Responsabilité tertiaire]

## Outils disponibles
[Liste des noms d'outils et de brèves descriptions]
Niveaux d'autonomie par outil :
- AUTO : [liste des outils de lecture/recherche]
- AUTO+ : [liste des outils d'exécution à faible risque]
- PROPOSE : [liste des outils à risque moyen nécessitant une fenêtre de retour arrière]
- CONFIRM : [liste des outils à risque élevé nécessitant une approbation explicite]
- BLOCK : [liste des actions absolument interdites]

## Contraintes comportementales
- JAMAIS [contrainte absolue 1]
- JAMAIS [contrainte absolue 2]
- TOUJOURS [exigence positive 1]
- TOUJOURS [exigence positive 2]

## Format de sortie
[Comment l'agent communique ses résultats — format, verbosité, usage des emojis, etc.]

Le SOUL est le document le plus important que vous allez rédiger. Un SOUL vague produit un comportement imprévisible. Un SOUL précis produit des agents fiables et auditables.

Voici un exemple concret — extrait du SOUL d’un agent commercial :

## Mission
Sami gère le pipeline commercial d'Inscape Interiors — identifier les prospects,
les scorer selon leur probabilité de conversion, rédiger des séquences de
relance, et s'assurer qu'aucune opportunité ne reste sans action appropriée.
Sami n'envoie jamais d'emails de manière autonome ; il propose toujours des
brouillons à la validation d'Islem.

## Contraintes comportementales
- JAMAIS envoyer un email de manière autonome — toutes les communications sortantes requièrent une approbation PROPOSE
- JAMAIS promettre de dates de livraison — toujours déférer à Pawel pour la confirmation des délais
- JAMAIS scorer un prospect au-dessus de 8/10 sans documenter le raisonnement
- TOUJOURS signaler les prospects des secteurs réglementés (services financiers, santé) à Islem
- TOUJOURS inclure les mentions de concurrents dans les notes de prospect quand elles sont détectées

Notez la précision des contraintes. “Ne rien faire de mauvais” n’est pas une contrainte. “JAMAIS promettre de dates de livraison” en est une.

Étape 2 : Configurer l’accès aux outils via les serveurs MCP

Les outils sont ce qui donne aux agents la capacité d’agir sur le monde réel. Dans Klawty OS, chaque outil est exposé via un serveur MCP — un processus léger qui encapsule un service externe et expose ses capacités via le protocole standardisé Model Context Protocol.

Sélectionner les serveurs MCP préconstruits

Klawty intègre des serveurs MCP préconstruits pour les intégrations enterprise les plus courantes :

Communication :

• Gmail / Google Workspace (lecture, brouillon, envoi — avec contrôles par niveau)
• Outlook / Microsoft 365
• Slack (publication, recherche, gestion des canaux)
• Discord (messagerie, réactions, gestion des fils)

Productivité :

• Google Calendar (lecture, création, modification d’événements)
• Notion (lecture/écriture de pages et bases de données)
• Linear (issues, projets, cycles)

Développement :

• GitHub (dépôts, PR, issues, actions)
• GitLab (intégration pipeline complète)

Métier :

• Salesforce (contacts, opportunités, cas)
• HubSpot (contacts, deals, historique)
• Stripe (données de paiement et d’abonnement — lecture seule recommandée)

Données :

• PostgreSQL (lecture seule ou lecture/écriture selon le rôle de l’agent)
• Google Sheets / Excel (synchronisation de données)

Configurer les niveaux de risque des outils

Pour chaque outil auquel votre agent a accès, vous attribuez un niveau d’autonomie. Ce n’est pas une question de capacité — c’est une question de risque :

// Dans agents/tools/sami-tools.js
const SAMI_TOOLS = {
  // AUTO — lecture pure, risque zéro
  'search_crm_contacts': { tier: 'AUTO', description: 'Rechercher des contacts dans le CRM' },
  'get_lead_score': { tier: 'AUTO', description: 'Calculer le score d\'un prospect' },
  'search_web': { tier: 'AUTO', description: 'Rechercher des informations sur un prospect en ligne' },

  // AUTO+ — écritures journalisées mais à faible risque
  'update_lead_stage': { tier: 'AUTO_PLUS', description: 'Mettre à jour l\'étape du pipeline dans le CRM' },
  'add_crm_note': { tier: 'AUTO_PLUS', description: 'Ajouter une note à un contact' },
  'create_task': { tier: 'AUTO_PLUS', description: 'Créer une tâche de suivi' },

  // PROPOSE — visible par le prospect ou difficile à annuler
  'draft_email': { tier: 'PROPOSE', description: 'Rédiger un email de relance pour validation' },
  'schedule_meeting': { tier: 'PROPOSE', description: 'Proposer une invitation calendrier' },

  // CONFIRM — approbation explicite d'Islem requise
  'send_proposal_doc': { tier: 'CONFIRM', description: 'Envoyer un document de proposition formelle' },
  'create_deal': { tier: 'CONFIRM', description: 'Créer un deal CRM supérieur à 10 000 €' },

  // BLOCK — no-op codé en dur
  'delete_contact': { tier: 'BLOCK', description: 'Supprimer des contacts n\'est jamais autorisé' },
  'modify_pricing': { tier: 'BLOCK', description: 'Les modifications de tarif relèvent d\'Islem directement' },
};

Cette configuration constitue l’architecture de sécurité de votre agent. Prenez le temps de la définir soigneusement.

Étape 3 : Configurer la file de tâches

Les agents Klawty opèrent sur une file de tâches — plutôt que d’avoir un accès continu et non contraint aux appels LLM, chaque cycle d’agent traite des tâches issues d’une file. Cela présente plusieurs avantages :

• Auditabilité — chaque action de l’agent correspond à une tâche avec un historique complet
• Limitation du débit — prévient les boucles d’agents incontrôlées
• Visibilité humaine — l’interface Task Manager affiche exactement ce que fait chaque agent
• Priorisation — les tâches urgentes passent en tête de file

Une tâche dans Klawty ressemble à ceci :

{
  "id": "task_abc123",
  "agent": "sami",
  "type": "lead_follow_up",
  "title": "Relancer Marie Laurent — demande de consultation Inscape",
  "priority": "high",
  "status": "executing",
  "metadata": {
    "contact_id": "sf_00Q1234",
    "last_contact": "2026-03-18",
    "inquiry_type": "renovation_bureau"
  },
  "created_at": "2026-03-21T09:00:00Z"
}

Le Task Executor récupère cette tâche, exécute le cycle de réflexion de l’agent, capture les appels d’outils et enregistre le résultat — sans intervention humaine, sauf si un appel d’outil requiert une approbation de niveau PROPOSE ou CONFIRM.

Étape 4 : Configurer le cycle de réflexion

Le cycle de réflexion définit la fréquence d’exécution de votre agent et ce qu’il recherche à chaque cycle. Dans Klawty, les cycles sont pilotés par des processus planifiés via LaunchAgent (macOS) ou des services systemd (Linux/VPS) :

# /Library/LaunchAgents/com.klawty.sami.plist
# Exécute le cycle de réflexion de Sami toutes les 20 minutes
StartCalendarInterval:
  - Minute: 0
  - Minute: 20
  - Minute: 40

À chaque cycle, l’agent :

1. Récupère le contexte — lit les messages récents dans son canal, extrait les tâches pertinentes de la file, interroge la mémoire
2. Planifie — le LLM raisonne sur ce qu’il doit faire au regard du contexte actuel
3. Exécute — appelle les outils en séquence, en traitant les résultats de chaque appel
4. Rend compte — publie un résumé dans son canal Discord
5. Valide — les tâches terminées sont marquées comme telles ; de nouvelles tâches sont créées pour les actions de suivi

La durée du cycle dépend de l’urgence des tâches. Un agent de service client peut tourner toutes les 5 minutes. Un agent d’analyse peut tourner toutes les 60 minutes. La bonne cadence équilibre la réactivité et les coûts API.

Étape 5 : Activer la supervision Sentinel

Sentinel est le chien de garde de la gouvernance dans Klawty — un agent dédié à la surveillance de tous les autres agents. Avant qu’une action de niveau PROPOSE ou CONFIRM ne s’exécute, Sentinel la valide au regard de vos règles métier :

// Règles métier Sentinel (extrait)
const SENTINEL_RULES = [
  {
    rule: 'no_ceka_invoice_forwarding',
    check: (action) => !action.includes('CEKA PRO'),
    message: 'Les factures CEKA PRO relèvent d\'Islem personnellement — pas de transfert automatique'
  },
  {
    rule: 'no_delivery_promises',
    check: (action) => !action.match(/livraison|délai|pour (lundi|mardi|mercredi|jeudi|vendredi)/i),
    message: 'Les engagements de livraison nécessitent la confirmation de Pawel au préalable'
  },
  {
    rule: 'email_requires_review',
    check: (action, tier) => action.type !== 'send_email' || tier === 'PROPOSE' || tier === 'CONFIRM',
    message: 'L\'envoi autonome d\'emails n\'est pas autorisé — doit être PROPOSE ou CONFIRM'
  }
];

Si une action proposée enfreint l’une des règles Sentinel, elle est bloquée avant exécution. L’agent reçoit la raison du blocage et peut soit réviser l’action, soit l’escalader vers un humain.

Étape 6 : Déploiement en production

Une fois le SOUL, les outils, la file de tâches, le cycle et Sentinel configurés, le déploiement se déroule ainsi :

# 1. Vérification syntaxique avant tout démarrage de service
node --check agents/sami/sami-runner.js

# 2. Charger le LaunchAgent
launchctl load ~/Library/LaunchAgents/com.klawty.sami.plist

# 3. Vérifier que le service a démarré
launchctl list | grep com.klawty.sami

# 4. Surveiller le premier cycle
tail -f /var/log/klawty/sami.log

# 5. Consulter l'interface Task Manager
open http://localhost:3000

L’interface Task Manager affiche le statut en temps réel de tous les agents, leurs tâches en cours, l’historique des appels d’outils et les propositions en attente d’approbation.

À quoi ressemble une journée de production

Une fois déployé, un agent Klawty opère de manière autonome. Pour Sami (agent commercial) lors d’une journée type :

• 09h00 — Sami s’exécute, examine les demandes reçues la nuit via le formulaire de contact
• 09h05 — Score 3 nouveaux prospects (niveau AUTO — aucune approbation requise)
• 09h06 — Propose un brouillon d’email de relance pour le prospect le mieux scoré (PROPOSE — fenêtre de 15 minutes)
• 09h08 — Islem examine, clique ✅ sur Discord — l’email est envoyé
• 09h15 — Le cycle suivant s’exécute, Sami vérifie le pipeline pour les deals bloqués
• 09h20 — Met à jour 2 étapes de deals dans le CRM (niveau AUTO+ — s’exécute et journalise)
• 11h20 — Signale une demande enterprise à haute valeur pour une réponse de niveau CONFIRM (approbation explicite requise)
• 17h00 — Publie le résumé quotidien du pipeline dans le canal #leads-pipeline

Tout cela se passe sans qu’Islem ouvre un CRM, rédige un email de zéro ou gère un pipeline manuellement. L’agent gère la routine ; Islem gère les décisions à valeur ajoutée.

Les erreurs classiques lors du premier déploiement

1. Rédiger un SOUL trop vague “Aider l’équipe commerciale” n’est pas une mission. “Scorer les prospects quotidiennement, rédiger des séquences de relance pour les 3 prospects prioritaires, et signaler toutes les demandes enterprise à la réponse personnelle d’Islem” en est une.

2. Tout mettre en AUTO La tentation de rendre l’agent entièrement autonome est réelle — mais prématurée. Commencez avec PROPOSE pour tout ce qui implique une communication externe ou une modification de données. Passez à AUTO+ seulement après avoir observé l’agent prendre de bonnes décisions à plus de 50 reprises.

3. Ne pas lire les 10 premiers cycles manuellement Les premiers cycles révéleront des incompréhensions dans votre SOUL ou votre configuration d’outils. Lisez chaque ligne de log pendant le premier jour. Vous détecterez les problèmes avant qu’ils n’affectent de vraies opérations métier.

4. Ignorer Sentinel Sentinel peut sembler superflu — jusqu’au moment où l’agent tente d’envoyer à un client un email avec des tarifs incorrects. Configurez vos règles métier avant le déploiement, pas après.

5. Ne pas configurer la mémoire Les agents sans mémoire se répètent — ils redécouvrent les mêmes informations à chaque cycle, envoient la même relance deux fois, perdent le contexte des conversations en cours. Configurez le Memory Distiller pour extraire des insights des tâches complétées et les stocker dans Qdrant.

Conformité EU AI Act intégrée

L’un des avantages distinctifs de Klawty OS pour les entreprises européennes est que la conformité réglementaire n’est pas une couche additionnelle — elle est intégrée à l’architecture.

Le Règlement sur l’IA de l’UE (applicable à partir d’août 2026) impose pour les systèmes IA à risque élevé : des traces d’audit complètes, des mécanismes de supervision humaine, de la transparence sur les décisions automatisées, et de la documentation technique. Klawty satisfait ces exigences par défaut :

• Traces d’audit — chaque appel d’outil, chaque tâche, chaque proposition est enregistrée en base SQLite avec horodatage et résultat
• Supervision humaine — les niveaux PROPOSE et CONFIRM garantissent qu’un humain peut intervenir sur toute action à risque significatif
• Transparence — l’interface Task Manager rend visible en temps réel tout ce que fait chaque agent
• Documentation technique — le SOUL.md constitue la documentation de conception de l’agent au sens du Règlement

Pour les déploiements dans des secteurs réglementés (finance, santé, administration publique), Klawty peut être hébergé sur infrastructure EU-souveraine chez Hetzner (Allemagne) ou OVH (France), garantissant la résidence des données sur le sol européen et la conformité RGPD.

Commencer avec Klawty

Klawty OS est disponible en déploiement auto-hébergé ou en service entièrement géré :

Auto-hébergé — Téléchargez Klawty OS et déployez sur votre propre infrastructure. Idéal pour les entreprises disposant d’équipes techniques et d’exigences de souveraineté des données.

Géré par dcode — Nous déployons, configurons et opérons les agents Klawty pour votre compte. Inclut la surveillance, la réponse aux incidents et l’optimisation continue. À partir d’un seul agent, extensible jusqu’aux équipes multi-agents complètes. Découvrez notre offre Klawty.

Agent-as-a-Service — Des agents préconstruits (Sami le Commercial, Falco le Financier, Zara le Marketing, Nour les Opérations) disponibles sous forme d’abonnements mensuels. Le chemin le plus rapide vers la production. En savoir plus sur l’AaaS.

Islem Binous est le fondateur de dcode Technologies et l’architecte du système multi-agents à 8 agents d’Inscape Interiors — l’un des déploiements MAS réels les plus avancés d’Europe. Chaque pattern décrit dans ce guide a été acquis en opérant des agents en production pour de vraies opérations métier.