Votre agent IA lit votre code. Qui en garde une copie ?

Il est 23 h. L’export des commandes plante, votre développeur est en congé, et un client attend son fichier demain matin. Vous ouvrez votre agent de code, vous décrivez le problème. Quelques minutes plus tard, l’export repart.

Pour y arriver, l’agent a lu le fichier d’export, le schéma de votre base, peut-être votre configuration. Si le bug ne se reproduisait qu’avec de vraies lignes, il a pu lancer une requête sur vos données. Avec un modèle distant, tout ce qu’il joint à sa demande quitte votre poste : selon l’outil et ses réglages, du code confidentiel, un secret de configuration, des données clients.

POST https://api.fournisseur-ia.example/v1/chat/completions
{
  "messages": [
    { "role": "system", "content": "Tu es un agent de code… (≈ 20 000 tokens d’instructions et d’outils)" },
    { "role": "user",   "content": "L’export des commandes plante, corrige-le." },
    { "role": "tool",   "content": "app/exports/orders_export.rb — 214 lignes de votre code" },
    { "role": "tool",   "content": "db/schema.rb — la structure de toute votre base" },
    { "role": "tool",   "content": ".env — DATABASE_URL=postgres://admin:•••@…" },
    { "role": "tool",   "content": "SELECT * FROM customers LIMIT 3 → Martin Sophie, s.martin@…, 12 rue…" }
  ]
}

Ce n’est pas une raison d’arrêter. Ces outils font gagner un temps considérable, et nous les utilisons tous les jours. C’est une raison de savoir trois choses : ce qui part, où c’est traité, et ce qu’il en reste.

Les fournisseurs répondent souvent par trois lettres : ZDR, pour Zero Data Retention, « zéro conservation des données ». Ils s’engagent à ne garder ni vos prompts (ce que l’agent envoie), ni les réponses du modèle[1][2].

Trois réflexes avant de vous en contenter :

• Vérifiez le périmètre. Le sigle ne dit ni quels services sont couverts, ni les exceptions, ni ce qui est gardé à côté[1][2][3]. Seules les conditions de votre offre, et des fonctions que vous utilisez, font foi.
• Ne confondez pas « pas d’entraînement » et « pas de conservation ». S’engager à ne pas entraîner un modèle sur vos données ne veut pas dire ne pas les stocker[1].
• Attendez-vous à des métadonnées[3]. Facturer et sécuriser un service demande de savoir qui a appelé, quand, avec quel volume. C’est normal. Ce qui ne l’est pas, c’est de ne pas vous dire lesquelles, ni pendant combien de temps.

L’auto-hébergement permet d’inspecter davantage de maillons. Il ne supprime ni la dépendance à l’hébergeur, ni le travail d’exploitation.

Cette troisième colonne a longtemps semblé réservée aux grands comptes : un serveur capable de faire tourner un modèle correct coûte environ 1 100 € par mois s’il reste allumé jour et nuit[6]. C’est ce chiffre que nous avons voulu faire tomber.

Chez Imagine-App, nous sommes trois associés à coder avec des agents. Un vendredi après-midi, nous avons décidé d’essayer la troisième option pour de vrai. Le lundi matin, chacun avait sa clé :

• un modèle ouvert, utilisable commercialement (licence Apache 2.0)[7][8], sur un serveur à carte graphique (GPU) chez Scaleway, à Paris ;
• une clé personnelle par associé, branchée dans nos agents de code (opencode et T3 Code) ;
• une configuration conçue pour traiter prompts et réponses sans les écrire sur disque ni dans les journaux ; lors du test du 9 novembre 2026, aucun marqueur n’a été retrouvé dans les journaux et fichiers examinés sur nos deux serveurs (nous publions la méthode et ses limites dans cette série) ;
• un petit serveur « veilleur » qui éteint le GPU après dix minutes sans requête et le rallume à la demande (nous détaillons son architecture dans un autre article).

Ce dernier point change l’équation : éteint, le GPU ne facture plus le calcul[9]. Voici nos frais d’hébergement estimés, aux tarifs publics de Scaleway, hors taxes[6][9][10][11][12].

Ces montants supposent 22 jours ouvrés, un démarrage par jour et dix minutes d’attente avant l’extinction. Ce sont des heures de serveur partagé, pas des heures par personne ; l’installation et l’administration ne sont pas comptées. En dehors du fixe, un message isolé, GPU éteint, revient à environ 0,40 €, et une heure de travail à environ 1,90 €.

On ne paie donc pas au mot, mais au temps où le GPU est allumé. À durée égale, que trois personnes s’en servent ou une seule, la facture est la même. Deux heures par jour, c’est l’ordre de grandeur de quelques abonnements d’IA pour une équipe[13]. À une différence près : le serveur est à Paris, et c’est nous qui l’administrons.

• Le modèle n’est pas le meilleur du marché. Nous avons validé le branchement et des tâches simples. Cela ne dit pas s’il peut remplacer le modèle de votre équipe : il faut le comparer sur vos tâches représentatives, en comptant le temps de correction humaine.
• Le premier message attend. GPU éteint, le démarrage prend trois à cinq minutes ; dans les deux outils que nous utilisons, l’agent patiente et réessaie seul. Le premier message d’une session prend ensuite une trentaine de secondes.
• Le réveil n’est pas garanti. Chaque extinction rend la machine à Scaleway[9]. Au démarrage suivant, il faut qu’un GPU soit libre. Un lundi matin, il n’y en avait plus de notre modèle cible : nous avons basculé sur deux cartes plus petites, à un tarif voisin[6], environ 30 % plus lentes en génération de code, sans supprimer le risque (nous racontons cette matinée dans la série). Ce fonctionnement convient à une équipe qui peut tolérer une indisponibilité.
• L’hébergeur garde un accès technique. Comme tout hébergeur, Scaleway peut techniquement accéder à la mémoire de ses machines[14]. Une offre qualifiée SecNumCloud renforce le cadre de sécurité[15], sans rendre à elle seule cette mémoire inaccessible ; une protection matérielle de la mémoire, vérifiable par attestation, répond à une autre exigence[14]. Notre prototype n’a ni l’une ni l’autre.
• Pas de haute disponibilité. Un serveur, trois utilisateurs.

Le choix n’est pas binaire. Il s’agit de trier.

• Un prototype, une page de présentation, un script jetable : un fournisseur standard fait très bien l’affaire.
• Le cœur de votre produit : au minimum, des conditions de non-conservation que vous avez lues.
• Des données clients, ou du code confié sous clause de confidentialité : vérifiez d’abord ce que vos contrats et vos obligations permettent de transmettre. Un hébergement en France répond à une exigence de localisation ; il ne suffit pas à rendre un traitement conforme. Pour la santé et les secteurs régulés, le cadre contractuel et les certifications nécessaires s’examinent avant tout envoi. Notre prototype ne démontre pas cette conformité.

Une configuration hybride convient souvent : un modèle de pointe pour les tâches non sensibles, un modèle privé lorsque vos obligations permettent d’y envoyer les données concernées, et une règle écrite qui précise aussi ce qui ne doit partir nulle part.