Sur une instance publique, une clé de serveur est une clé partagée

Un de nos outils devait pouvoir faire appel à un modèle qui raisonne. La solution évidente était de mettre la clé d'API dans la configuration du serveur. C'est ce qu'on allait faire. C'était une erreur, et elle a été arrêtée par une question de trois mots : « sur l'instance en ligne ? »

1. Pourquoi l'évidence était fausse

Une clé d'API dans la configuration d'un serveur, c'est une clé du serveur. Sur une machine personnelle, pour une seule personne, c'est parfaitement raisonnable. Sur une instance ouverte à qui veut créer un compte, ça devient autre chose : chaque utilisateur consomme le crédit du propriétaire.

Pas par malveillance. Par fonctionnement normal. L'outil marche, les gens s'en servent, et la facture arrive chez quelqu'un qui n'a rien demandé. La seule issue serait de fermer l'inscription — c'est-à-dire de renoncer à ce que l'outil serve à quelqu'un d'autre.

La bonne question n'est donc pas « où range-t-on la clé ». C'est « à qui appartient-elle ».

2. Ce qu'on a construit à la place

Chaque compte renseigne sa propre clé, depuis l'application. Elle est chiffrée avant d'être enregistrée, avec un algorithme qui authentifie aussi le contenu : une base modifiée à la main ne se déchiffre pas, elle est rejetée. Elle n'est jamais renvoyée — pas même à celui qui l'a posée. On affiche seulement les derniers caractères, pour qu'il reconnaisse la sienne.

Une clé mal formée est refusée sans aucun appel réseau. Une clé de forme valide mais fausse est refusée par le fournisseur — ce qui prouve au passage que la vérification a lieu. Et la clé d'un compte n'existe pas pour un autre : deux comptes, deux crédits, aucun recouvrement.

3. Le piège qu'on a évité : tout ou rien

Le réflexe suivant aurait été de dire : pas de clé, pas d'outil. Ç'aurait été plus simple à écrire, et ç'aurait tué l'intérêt du projet. Quelqu'un qui découvre un outil ne va pas créer un compte chez un fournisseur, obtenir une clé et la coller, pour voir si l'outil lui plaît.

Il y a donc deux modes, et le premier n'a besoin de rien. Sans clé, l'analyse se fait par comptage pondéré de mots-clés et les exercices viennent de ceux écrits à la main : ça fonctionne, c'est gratuit, et c'est le mode par défaut de tout nouvel arrivant. Avec sa clé, l'utilisateur débloque la lecture par un modèle qui raisonne et la génération dans n'importe quel métier.

Le mode simple n'est pas une version dégradée qu'on tolère. C'est celui que verront la plupart des gens, et il doit être bon tout seul.

4. Le détail qui compte

Il reste un cas légitime : une installation personnelle, sur sa propre machine, où l'on veut une clé unique plutôt que de la reposer dans son profil. On l'a gardé — mais il exige deux réglages : la clé, et un drapeau explicite qui dit « oui, je veux la partager ».

Une clé seule ne suffit pas, et c'est voulu. Recopier une ligne de configuration trouvée quelque part ne doit jamais suffire à offrir son crédit à tous les comptes d'une instance. Le geste dangereux doit demander une phrase de plus que le geste anodin.

🔭