Depuis deux ans, les outils de développement assisté par IA se sont installés dans les équipes techniques. Et avec eux, deux questions que personne ne se posait avant : où part le code de l’entreprise quand un développeur tape un prompt, et combien coûte réellement cette assistance une fois multipliée par le nombre d’utilisateurs.
La plupart des offres du marché répondent par le même modèle : un abonnement mensuel par utilisateur, un éditeur qui choisit le modèle à votre place, et une politique de traitement des données qu’il faut aller chercher dans les conditions générales. OpenCode propose l’inverse. C’est un point d’entrée intéressant pour comprendre ce que « souveraineté » veut dire concrètement quand on parle d’IA de développement.
OpenCode en deux paragraphes
OpenCode est un agent de code open source, publié sous licence MIT. Il s’utilise principalement dans le terminal : vous le lancez dans le dossier de votre projet, vous décrivez une tâche en langage naturel, et l’agent explore le code, modifie des fichiers, exécute des commandes et enchaîne les étapes en s’arrêtant pour que vous validiez. Il existe aussi une application desktop et une extension pour éditeur, mais le coeur du produit reste le terminal.
Deux différences structurelles avec les outils propriétaires. D’abord, le modèle n’est pas imposé : OpenCode se connecte à des dizaines de fournisseurs (Anthropic, OpenAI, Google, modèles ouverts) et vous pouvez en changer selon la tâche. Ensuite, le mode de facturation par défaut est le BYOK, bring your own key : vous branchez vos propres clés d’API et vous payez votre consommation réelle au fournisseur, pas un forfait à l’éditeur de l’outil.
Ce que « souverain » veut vraiment dire ici
C’est là qu’il faut être précis, parce que le marketing du secteur entretient une confusion utile.
OpenCode annonce ne pas stocker votre code ni vos données de contexte : l’agent tourne sur votre machine, et l’exception principale est la fonction de partage de session, qui envoie l’historique en ligne pour le rendre consultable dans un navigateur. C’est une garantie réelle, et elle est vérifiable puisque le code est ouvert.
Mais elle ne signifie pas que votre code reste chez vous. En BYOK, vos prompts et vos fichiers partent chez le fournisseur de modèle que vous avez branché, qui applique sa propre politique de rétention et d’entraînement. Autrement dit : l’outil ne s’interpose plus comme un intermédiaire qui conserve vos données, mais la question du destinataire final reste entière, et c’est vous qui la tranchez.
C’est précisément l’intérêt pour une PME. Vous passez d’une situation où vous subissez une chaîne de traitement à une situation où vous la choisissez, contrat par contrat.
Les trois niveaux de confidentialité à arbitrer
Selon la sensibilité du projet, trois configurations sont possibles avec le même outil.
Niveau 1 : API grand public. Vous branchez une clé d’API standard. C’est le plus simple et le moins cher à mettre en oeuvre. À réserver aux projets sans données sensibles : un site vitrine, un prototype interne, des scripts d’automatisation.
Niveau 2 : offre entreprise avec engagement de non-entraînement. La plupart des grands fournisseurs proposent des conditions professionnelles où les données envoyées via l’API ne servent pas à entraîner les modèles, avec des durées de rétention encadrées. C’est le bon niveau pour la majorité des applications métier. Il demande de lire les conditions du fournisseur choisi, pas celles de l’agent.
Niveau 3 : modèle local. OpenCode sait se connecter à un modèle qui tourne sur votre propre infrastructure. Le code ne sort alors jamais de votre réseau. C’est la seule configuration réellement hermétique. Le prix à payer est technique : il faut une machine capable de faire tourner le modèle, et la qualité des résultats reste en dessous des meilleurs modèles hébergés. C’est un arbitrage à faire projet par projet, pas une position de principe.
Aucun outil propriétaire ne vous laisse déplacer ce curseur. C’est ça, la différence concrète.
Le volet coûts : forfait contre consommation réelle
Sur le papier, l’abonnement rassure : un montant fixe, prévisible, entre 20 et 40 dollars par utilisateur et par mois selon les offres du marché. Sur une équipe de dix personnes, cela représente plusieurs milliers d’euros par an.
Le BYOK inverse la logique. Vous payez ce que vous consommez, ce qui donne deux résultats opposés selon les usages :
- Pour un utilisateur occasionnel, quelques sessions par semaine, la facture réelle tombe souvent très en dessous du prix d’un abonnement. Un développeur qui utilise l’agent deux heures par semaine ne paie pas la même chose qu’un forfait dimensionné pour un usage intensif.
- Pour un utilisateur intensif sur un gros dépôt, la consommation peut dépasser le forfait. Les agents relisent beaucoup de contexte, et le coût suit.
L’inconvénient honnête du BYOK, c’est l’imprévisibilité : sans garde-fous, la facture n’est connue qu’à la fin du mois. En pratique, cela se gère avec des plafonds de dépense par clé chez le fournisseur, et une clé distincte par projet ou par équipe pour savoir où part l’argent. C’est cinq minutes de configuration au départ.
Le second avantage, moins visible : la possibilité de router les tâches selon leur valeur. Un modèle rapide et bon marché pour la reformulation ou la génération de tests, un modèle haut de gamme pour les refontes délicates. Avec un forfait, vous payez le même prix quoi que vous fassiez.
Quand ce n’est pas le bon choix
Trois cas où nous déconseillons de partir sur ce type d’outil.
Si votre équipe n’a pas de culture du terminal, l’expérience sera frustrante et l’adoption ne suivra pas. Un éditeur graphique intégré sera plus efficace, même s’il coûte plus cher.
Si vous cherchez de l’autocomplétion pendant la frappe, ce n’est pas le même produit. Un agent travaille par tâches, pas ligne à ligne.
Si personne en interne ne veut prendre la responsabilité du choix des modèles et des clés, l’abonnement propriétaire est un service que vous achetez, et c’est un choix légitime. La liberté a un coût administratif.
Il faut aussi rappeler un risque commun à tous les agents, quel que soit leur éditeur : il devient très facile d’accepter des modifications qu’on n’a pas vraiment lues. Le mode plan, qui fait décrire l’intention avant toute écriture de fichier, existe pour ça. L’utiliser n’est pas une précaution excessive, c’est la base.
Une checklist avant de déployer en PME
- Définir les dépôts autorisés et ceux qui restent hors périmètre.
- Choisir un fournisseur de modèle et vérifier ses engagements de non-entraînement et de rétention, par écrit.
- Fixer un plafond de dépense mensuel par clé d’API.
- Décider si la fonction de partage de session est autorisée ou désactivée.
- Écrire un fichier de règles à la racine du dépôt (conventions, interdits, contexte métier) pour que l’agent travaille dans votre cadre et pas dans le sien.
- Imposer la relecture humaine des diffs avant commit, et l’écrire dans le processus.
Ce que nous en retenons
L’intérêt d’OpenCode pour une PME n’est pas d’être gratuit. Il est de rendre visibles et négociables trois décisions que les offres par abonnement prennent à votre place : où part votre code, quel modèle le traite, et combien vous payez pour ça.
C’est plus de travail au démarrage. En échange, vous ne vous retrouvez pas dans deux ans avec un outil dont vous ne pouvez plus sortir, ni avec du code propriétaire parti chez un tiers que vous n’aviez pas choisi.
Chez Nokodeurs, nous accompagnons les PME sur ces arbitrages : quel outil pour quel usage, quel niveau de confidentialité pour quel projet, et comment cadrer l’usage de l’IA dans une équipe de développement. Si vous êtes en train de vous poser la question, parlons-en.