Partager une facture d'IA unique au sein d'un foyer

openplate fonctionne selon le principe du « bring-your-own-key » : chaque personne pointe l'application vers un fournisseur d'IA et paie ses propres analyses de photos d'assiette. À l'échelle d'un foyer, c'est absurde. Personne ne veut gérer quatre comptes fournisseurs, et partager une seule clé est pire : impossible de savoir qui a dépensé quoi, et révoquer une personne revient à révoquer tout le monde.

Tu n'as pas besoin de serveur pour cela. La solution se trouve chez le fournisseur : un seul compte, une clé par personne, un plafond de dépense par clé. Lis cette section en premier ; les deux solutions basées sur un serveur, plus bas, traitent les cas qu'elle ne couvre pas.

Rien ici ne partage de journal. Le journal alimentaire de chaque personne reste dans le stockage de son propre navigateur, sur son propre appareil. Ce qui transite sur le réseau se résume à l'envoi d'une photo et au retour d'une estimation. La personne qui paie la facture peut voir combien de requêtes chacun a effectuées et ce que cela a coûté. Elle ne peut pas voir ce que les autres ont mangé.

La version courte, avec OpenRouter

OpenRouter permet de générer autant de clés API que nécessaire sous un seul compte, chacune avec sa propre limite de crédit et sa propre ligne de consommation. C'est exactement ce dont un foyer a besoin.

1. 01
   Une personne crée le compte sur openrouter.ai et ajoute du crédit. Seule cette personne s'y connecte ; personne d'autre n'a besoin d'un compte.
2. 02
   Ouvre la page Keys et crée une clé par personne. Donne à chaque clé le nom de la personne : c'est ce nom que tu liras plus tard dans le détail de la consommation, donc « Sam » vaut mieux que « clé 3 ».
3. 03
   Définis une limite de crédit sur chaque clé au moment de sa création. C'est le plafond. Une clé sans limite peut consommer tout le solde du compte, alors considère la valeur « unlimited » comme la chose à éviter ici.
4. 04
   Envoie à chaque personne sa propre clé. Transmets-la comme tu transmettrais un mot de passe, pas dans une discussion de groupe qui reste pour toujours.
5. 05
   Chaque personne la colle. Dans openplate : Paramètres → IA, choisis OpenRouter, puis utilise le panneau « paste an API key manually ». La clé est stockée uniquement dans ce navigateur. Elle est exclue de l'export JSON et n'atteint jamais le serveur openplate.

C'est toute la configuration. Cinq minutes, aucun conteneur, aucune maintenance.

Utilisation

• Qui a dépensé quoi : le tableau de bord d'OpenRouter détaille l'utilisation par clé. Comme chaque clé porte le nom d'une personne, tu obtiens directement la facture par personne.
• Révoquer une personne : supprime sa clé. Personne d'autre n'est affecté, personne d'autre ne modifie de paramètre, et la personne révoquée n'a aucun recours : cette clé était son unique identifiant. Son journal reste intact, car il n'a jamais été stocké sur la clé.
• Donner plus à quelqu'un : augmente la limite de sa clé. La modification s'applique immédiatement, sans aucun redémarrage.
• La clé de quelqu'un ne fonctionne plus : la personne a atteint sa limite, ou tu as supprimé sa clé. openplate remontera l'erreur du fournisseur ; la solution se trouve sur la page Keys, pas dans l'application.

Plafonne aussi le compte, pas seulement les clés. Les plafonds par clé limitent chaque personne, mais c'est bien le solde du compte qui est débité. Conserve un solde dont la perte ne te poserait pas de problème, et recharge-le manuellement.

Automatisation. OpenRouter propose aussi une API pour créer et gérer des clés via des scripts, ce qui est utile si tu provisionnes des accès pour plus d'une poignée de personnes. Pour une famille, utiliser le tableau de bord est plus rapide que d'écrire un script.

L'autre solution : une instance gérée d'openplate-core

Si ton fournisseur ne délivre pas de sous-clés plafonnées (Mistral, la plupart des API directes de fournisseurs), la méthode des sous-clés décrite plus haut ne peut rien faire. C'est précisément l'intérêt d'une instance gérée d'openplate-core : définis INSTANCE_MODE=managed (nécessite CORE_URL), et le service de comptes que ton foyer utilise déjà pour la synchronisation devient également le proxy d'IA, avec un quota quotidien de requêtes par compte.

Choisis cette option plutôt que les sous-clés de fournisseur quand :

• Ton fournisseur ne propose aucune limite de dépense par clé, donc le plafond doit être géré à un endroit que tu contrôles.
• Tu veux un plafond quotidien de requêtes par personne plutôt qu'un solde de crédits par personne.
• Tu fais passer le foyer par ta propre machine openplate-inference, où il n'y a aucun tableau de bord de fournisseur : une instance gérée ajoute le quota par personne et le suivi de consommation que la liste d'autorisations API_KEYS ci-dessous ne possède pas.
• Tu veux que la révocation se fasse en une seule action dans l'écran d'administration, plutôt que de devoir distribuer une clé partagée que tout le monde doit recoller.

Garde les sous-clés de fournisseur quand tu le peux. Si tu utilises OpenRouter, tu as déjà terminé depuis cinq minutes et il n'y a aucun service à maintenir en fonctionnement.

Configuration : démarre openplate-core (voir sync.md et topologies.md), puis configure INSTANCE_MODE=managed dans l'application openplate. Fais pointer le serveur central vers ton fournisseur à l'aide de UPSTREAM_BASE_URL, UPSTREAM_API_KEY et AI_ADVERTISED_MODEL dans .env. La dernière ligne est obligatoire. Sans modèle, l'application ne réalise aucune analyse. Génère la première invitation, pour toi-même, sur le serveur avec ADMIN_TOKEN, en tant qu'administrateur (self-hosting.md donne la commande). À partir de là, invite des personnes depuis /admin dans l'application, en attribuant un quota journalier à chaque compte. Si le courrier électronique est configuré sur le serveur central, l'invitation est envoyée par e-mail à la personne. Sinon, /admin t'affiche le lien, et tu l'envoies comme tu le ferais pour un mot de passe. La procédure est identique en cas d'oubli de mot de passe. Sans serveur de messagerie configuré, l'utilisateur te sollicite, et tu crées le lien de réinitialisation sous Personnes dans /admin. Chaque personne se connecte et son compte intègre d'office la connexion à l'IA. Il n'y a aucune étape supplémentaire ni rien à coller. La suspension ou la réactivation d'un compte s'effectue sur ce même écran d'administration, avec effet immédiat.

Deux points à connaître avant de t'appuyer dessus. Le quota comptabilise les requêtes et non les devises, garde donc aussi un plafond de dépense strict sur la clé en amont chez le fournisseur : seul le fournisseur peut bloquer les dépenses financières. De plus, le quota d'une personne est défini explicitement par compte ; il n'y a pas de valeur illimitée par défaut.

La synchronisation et le proxy d'IA forment désormais le même service, donc le serveur d'une instance gérée voit plus de choses que celui d'une instance non gérée : une adresse e-mail, du texte chiffré pour lequel il n'a aucune clé, et, lors d'une analyse, la photo, lue une seule fois sans être stockée. Il ne voit toujours aucune entrée de journal en clair. Consulte architecture.md pour avoir la vue complète de ce que chaque composant conserve.

L'alternative : une machine d'inférence partagée

Si tu possèdes le matériel, l'autre façon de partager une facture consiste à n'avoir aucune facture. Fais tourner openplate-inference sur une machine chez toi, et chaque analyse de la maison est calculée localement, sans aucun fournisseur cloud. Consulte topologies.md pour voir ce que cela te coûte en matériel et en maintenance : c'est bien plus exigeant que de coller cinq clés dans un tableau de bord.

Elle dispose aussi de clés par personne, même si elles sont plus sommaires. API_KEYS sur le conteneur d'inférence est une liste séparée par des virgules de clés de type bearer acceptées :

-e API_KEYS="opk_alex_...,opk_sam_...,opk_robin_..."

Donne à chaque personne une entrée de cette liste, et chacun colle la sienne dans openplate sous Paramètres → IA → Compatible OpenAI avec l'URL de base de l'instance (par exemple http://openplate.example.lan:8300/v1) et le modèle openplate-plate-1. Retirer une clé de la liste puis redémarrer révoque uniquement cette personne.

Deux limites bien réelles par rapport aux sous-clés des fournisseurs :

• Il n'y a pas de limite de dépense ni de quota par clé. Cette liste n'est qu'une liste d'autorisation, rien de plus. Cela convient très bien lorsque la ressource est ton propre GPU inutilisé et qu'aucun coût n'est lié à une requête.
• C'est à toi de générer et de distribuer les clés. N'importe quelle chaîne aléatoire fonctionne (openssl rand -base64 24) ; il n'y a pas de tableau de bord, ni de rapport d'utilisation par personne : tu as les journaux du conteneur.

Liste complète des variables : docs/configuration.md de openplate-inference.

N'utilise pas le raccourci de l'IA fournie par l'instance pour cela. Définir DEFAULT_INFERENCE_API_KEY sur openplate permet à tout le monde d'y accéder en un geste sans coller de clé, mais cette clé est intégrée dans le code HTML de la page et lisible via le code source par toute personne pouvant ouvrir l'application. Il s'agit donc à nouveau d'un identifiant partagé, avec le même problème qu'au départ. Cela convient pour un réseau local ou un tailnet où tu as confiance en chaque personne qui y accède, mais pas ailleurs. Consulte configuration.md.

Comptes pour la famille

La synchronisation et une instance gérée donnent toutes deux à chaque personne un compte sur le service openplate-core que tu exécutes.

• Utilise les invitations. Tu crées le premier compte pour toi-même sur le serveur (self-hosting.md contient la commande). Ensuite, invite chaque personne depuis /admin dans l'application.
• Garde OPEN_SIGNUP désactivé. Cela permet à quiconque trouve l'adresse de demander un compte. Une famille n'en a aucune utilité.
• Le courrier électronique est facultatif. Sans courrier électronique, /admin affiche chaque lien d'invitation et de réinitialisation, et tu le transmets toi-même. self-hosting.md explique les deux méthodes, ainsi que la configuration des courriels si tu le souhaites.