Pour celles et ceux qui éditent un logiciel

Mettez des agents IA dans votre produit, pas vos clients dans un cloud.

Vos clients vous réclament de l’IA, et la solution évidente vous déplaît : ouvrir un compte chez un fournisseur, y faire transiter leurs données, et facturer par-dessus des jetons dont vous ne fixez pas le prix. Apollia OS est l’autre voie. C’est un runtime, autrement dit le programme qui fait tourner des agents et leur donne des outils, et il s’installe sur la machine de votre client comme n’importe quel autre morceau de votre produit.

Vous l’embarquez, vous le redistribuez, vous le facturez. La licence le dit noir sur blanc.

0.2.0-preview · MIT ou Apache 2.0 · Aucun serveur entre vous et vos clients

Licence
MIT ou Apache 2.0, au choix du preneur
Redistribution
Autorisée, y compris dans un produit fermé
Exécution
Sur la machine de votre client, sans relais
Interface
API HTTP locale, décrite en OpenAPI
Kit Python
Aucune dépendance tierce
Systèmes
macOS, Windows, Linux
AVANT DE REGARDER UNE LIGNE DE CODE

Quatre questions décident, et elles se posent toujours dans cet ordre.

Un éditeur n’évalue pas un runtime comme un développeur curieux. Il regarde d’abord ce qu’il a le droit de faire, ensuite ce qui risque de bouger sous ses pieds, puis ce qu’il devra maintenir, et enfin qui décroche le jour où un client appelle.

Le reste de la page répond, dans le même ordre.

  1. La licence me laisse-t-elle redistribuer ?

    Ce que la licence vous permet
  2. L’interface est-elle stable ?

    Ce sur quoi vous pouvez vous appuyer
  3. Qu’est-ce qui est livré, et sur quoi ?

    Ce que vous embarquez exactement
  4. Et quand ça casse en production ?

    À qui vous vous adressez
TROIS FAÇONS DE VOUS BRANCHER

Selon ce que vous construisez, l’intégration n’entre pas par la même porte.

Les trois coexistent et se combinent. Aucune ne demande d’écrire du Rust, et aucune ne suppose que vous ayez lu le code.

Le runtime Apollia sur la machine de votre client
La porte principale, celle que l’application et le terminal empruntent aussi. Une spécification OpenAPI produite depuis le code, deux clients dérivés, TypeScript et Python.

Trois entrées, un seul runtime : l’API locale que l’application et le terminal empruntent aussi, le kit Python pour écrire vos agents, et le protocole MCP pour que votre produit devienne un outil de l’agent. Elles coexistent et se combinent.

HTTP · 127.0.0.1

L’API locale

C’est la porte principale, et ce n’est pas une porte de service : l’application de bureau et la ligne de commande passent exactement par là. Ce que votre produit pilote, c’est donc le runtime entier, pas un sous-ensemble consenti aux intégrateurs.

Quand la choisirVotre produit n’est pas écrit en Python, ou tourne déjà comme un service.

from apollia import agent

Le kit Python

Un agent est une classe ordinaire : un décorateur au-dessus, une méthode asynchrone dedans, rien à hériter. Le kit n’installe aucune bibliothèque tierce, ce qui veut dire qu’il ne s’invite ni dans votre arbre de dépendances ni dans votre revue de licences, et c’est rarement une petite affaire chez un éditeur.

Quand la choisirLa logique que vous voulez automatiser est déjà en Python, ou va l’être.

mcp:votre-produit/…

Votre produit vu comme un outil

MCP est un protocole ouvert par lequel un logiciel déclare ce qu’il sait faire, dans un format qu’un modèle sait lire. Publiez un serveur MCP pour votre produit, et un agent Apollia s’en sert comme n’importe quel autre client du protocole. Vous écrivez l’intégration une fois, pas une par éditeur d’IA.

Quand la choisirVous voulez être pilotable par l’IA sans dépendre du choix d’un client.

Les trois surfaces du runtime, en détail Les outils sur lesquels un agent peut agir

CE QUE VOUS AVEZ LE DROIT DE FAIRE

MIT ou Apache 2.0. C’est vous qui choisissez, pas moi.

Oui, et commercialement. MIT ou Apache 2.0, vous prenez celle des deux qui passe votre revue juridique, et le produit dans lequel vous l’embarquez peut rester fermé.

Ce que ça vous permet

  • Intégrer Apollia OS dans un produit commercial, et le vendre.
  • Garder fermé le code de ce produit. Aucune des deux licences ne se propage à ce que vous écrivez autour.
  • Modifier le runtime, et garder vos modifications pour vous.
  • L’installer chez autant de clients que vous voulez, sans redevance, sans décompte de postes, sans clé à demander.
  • Le proposer en interne comme en externe, y compris à des clients qui n’auront jamais entendu le nom Apollia.

Ce que ça vous demande

  • Conserver l’avis de licence et de droit d’auteur dans ce que vous distribuez. C’est la seule obligation commune aux deux.
  • Sous Apache 2.0, signaler les fichiers que vous avez modifiés. En échange, elle porte une concession de brevet explicite.
  • Ne pas utiliser le nom ni le logo Apollia pour vendre le vôtre : la licence porte sur le code, pas sur la marque.

Pourquoi deux licences plutôt qu’une.

MIT tient en une page et passe partout. Apache 2.0 est plus longue parce qu’elle traite un point que MIT laisse ouvert : la concession des brevets qui couvrent le code. Publier les deux évite de vous imposer un arbitrage qui ne me regarde pas.

CE QUI PEUT BOUGER, ET CE QUI NE BOUGERA PAS

C’est une préversion, et il y a quand même un point fixe dedans.

La version publiée est 0.2.0-preview, et je ne vais pas vous la vendre pour une 1.0. Ce qui la rend tenable : la spécification de l’API est produite depuis le code, et la version que vous embarquez ne bouge que quand vous la faites bouger. Trois appuis, et ils sont vérifiables.

L’interface porte son numéro de version dans son adresse.

Une rupture de compatibilité arrive sous un nouveau préfixe, jamais par une mutation silencieuse de celui en place.

La spécification est produite par le code, pas à côté.

Un changement d’interface se lit donc dans un diff, ligne à ligne, au lieu d’être annoncé puis oublié.

C’est vous qui décidez du jour où la version change.

Le runtime tourne sur la machine de votre client, embarqué dans votre produit. Rien ne se met à jour sous vos pieds.

Et voici ce qui n’est pas encore écrit.

Le journal des versions annonce du versionnage sémantique. Ce qu’il ne dit pas encore, c’est quelle surface exactement ce versionnage couvre, ce que la ligne 0.x s’autorise, et à quoi ressemblerait un préavis de dépréciation. Je préfère vous le dire que vous promettre une politique que la 0.1.0 ne tiendrait pas.

En attendant, la consigne tient en une ligne, et elle est celle que j’appliquerais à votre place : épinglez la version que vous embarquez. Si vous construisez sur une surface autre que l’interface HTTP, écrivez-moi avant : je vous dirai ce que je compte déplacer.

CE QUI ENTRE DANS VOTRE PRODUIT

Un démon, deux processus qu’il surveille, et rien d’autre à administrer.

Un éditeur a besoin de savoir ce qu’il ajoute à son installeur avant de savoir ce que ça sait faire. Voici la liste, sans emballage, pour macOS Apple Silicon · Windows x86_64 · Linux x86_64.

Le démon
Le programme qui tient tout, et l’interface HTTP que votre produit appellera.
Deux processus surveillés
Le moteur d’inférence llama-server, qui fait tourner le modèle, et le sidecar de dictée.
Trois surfaces
Une application de bureau, une ligne de commande, et l’interface HTTP. Les trois ouvrent sur le même moteur.
Le kit Python
De quoi écrire des agents, sans aucune dépendance tierce à installer. Il se prend dans le dépôt, et il tient dans un dossier.
Pas de modèle
Aucun modèle n’est inclus dans les bundles. Votre client en choisit un au premier lancement et le télécharge.

Et « supporté par qui », puisque c’est la vraie question.

Apollia OS est développé par une personne. Ce qui tient la qualité n’est donc pas un comité de relecture, c’est une chaîne de contrôles automatiques qui vit dans le dépôt, tourne à chaque contribution, et que vous pouvez lire avant de me croire.

Les trois systèmes sont livrables. Deux d’entre eux passent cette chaîne de contrôle à chaque contribution ; Windows est construit et publié sans cette étape-là.

Ce qui tourne, pièce par pièce Le périmètre exact de la préversion

LE JOUR OÙ VOTRE CLIENT APPELLE

Vous écrivez à quelqu’un, et vous savez à qui.

Autant le dire dans la première phrase plutôt que dans une petite ligne : Apollia OS est développé par une personne. Je ne vends donc ni astreinte, ni délai de réponse contractuel, ni équipe de garde, et je ne vais pas faire semblant du contraire dans une page qui cherche à vous convaincre.

Ce qui rend cette absence supportable, c’est la forme du produit, et ce n’est pas un argument de rattrapage. Il n’y a aucun service distant qui puisse tomber sous le vôtre : ce que vous livrez tourne sur la machine de votre client, sans passer par une infrastructure que j’exploite, parce qu’il n’y en a pas. Une panne de mon côté n’a pas de chemin pour atteindre vos utilisateurs.

Vous cherchez plutôt un agent conçu pour votre métier et construit pour vous ? C’est un autre besoin, et il a sa page. Faire construire un agent sur mesure

  • Un défaut, une question technique Le dépôt public

    Une remontée écrite là est lisible par tout le monde, et la réponse sert au suivant.

  • Une intégration, un projet, un doute avant de vous engager contact@apollia.fr

    Dites ce que vous embarquez, sur quelle plateforme, et ce qui bloque.

  • Une vulnérabilité Le canal privé du dépôt

    La procédure de divulgation est écrite dans le dépôt et elle annonce ses délais.

CE QU’ON ME DEMANDE ENSUITE

Six questions qui arrivent juste avant la décision.

Elles reviennent presque toujours dans cet ordre, et les réponses sont les mêmes qu’en rendez-vous.

Prenez-le, ouvrez-le, et écrivez-moi ce qui manque.

La licence ne vous demande pas de me prévenir, et la préversion s’installe sans que vous ayez à me parler. Mais si vous envisagez sérieusement de l’embarquer, un échange en amont vous fera gagner des semaines : je connais les endroits qui vont bouger, et vous connaissez la contrainte de votre produit.

0.2.0-preview · MIT ou Apache 2.0 · macOS, Windows, Linux

Le périmètre exact de la préversion