Au début, Orazaka était une découverte. Un projet personnel, sur mon MacBook, pour comprendre ce qu'on peut faire avec des modèles d'IA qui tournent chez soi. Ollama pour le texte, le GPU du Mac (Metal) pour les images, une base de données et quelques services lancés à la main. Si on m'avait pris le portable, il n'y avait plus d'Orazaka.
Puis le projet s'est structuré, et j'ai décidé de le partager en open source. À partir de là, une question a pris toute la place : comment faire tourner ailleurs ce qui ne tournait que chez moi ? Ce billet raconte cette industrialisation, étape par étape, avec les options que j'ai pesées. Je ne parle ici que de choix écrits dans nos décisions d'architecture ou notre documentation.
Étape 1 : un monolithe sur un portable
Le premier Orazaka était un seul programme Java qui faisait tout : le chat, les tâches longues, les médias, l'identité. Il était déjà bien rangé à l'intérieur, et des règles d'architecture vérifiées à chaque build (ArchUnit) empêchaient une couche d'appeler n'importe quelle autre. Mais une seule application possédait toutes les données et toutes les portes d'entrée.
Le premier geste vers la portabilité a été de retirer les modèles du code. Avec la migration vers Spring Boot 4 et Spring AI 2, le choix du modèle est devenu une ligne en base, lue à chaque appel par un routeur. Un modèle local et un modèle hébergé passent par la même API. Je le raconte dans le billet sur le Mac. C'est la décision qui a rendu tout le reste possible : changer de machine ne veut plus dire changer de code.
Étape 2 : des services, sans tout casser
En juillet, j'ai découpé le monolithe en services (ADR-032). Pas d'un coup : avec le motif du « figuier étrangleur ». On place d'abord une façade devant, puis on sort un morceau à la fois derrière elle, et chaque étape doit passer les tests de bout en bout avant la suivante. Une base de données par service, chacune avec son rôle, et aucune clé étrangère entre deux services.
À ce moment-là, tout restait 100 % local : pas de CI, pas de cloud, c'était écrit dans la décision. Le Mac faisait encore tout tourner, mais il le faisait comme le ferait un serveur.
Ensuite est venu le partage du code en dépôts publics, une vingtaine, un par composant. C'était propre sur le papier, mais coûteux au quotidien : une modification qui traverse trois dépôts, c'est trois pull requests. Je suis en train de regrouper ce qui va ensemble.
Étape 3 : des conteneurs et une ligne de commande
Pour qu'une autre personne puisse lancer Orazaka, il fallait une seule porte d'entrée. C'est la ligne de commande :
npx orazaka install --server # sur un serveur Linux
orazaka start
orazaka doctor
orazaka models image listLes services et les bases tournent dans des conteneurs. Les modèles, eux, tournent au plus près du matériel : sur un Mac, directement sur Metal, parce que la virtualisation ne donne pas accès au GPU d'Apple.
La documentation de livraison pèse les options pour les conteneurs sur un Mac. Docker Desktop n'est pas redistribuable et devient payant pour les grandes organisations. OrbStack est excellent, mais demande une licence payante par utilisateur. Le choix par défaut est Colima, libre et scriptable, et si la machine a déjà l'un des deux autres, on l'utilise. Pour les grandes organisations, Kubernetes et Helm viendront plus tard, quand un client aura besoin de haute disponibilité. Pas avant.
Étape 4 : des GPU qui n'existent que pendant le travail
L'environnement de développement tourne maintenant dans le cloud, sans GPU. Mais il devait générer pour de vrai. La décision (ADR-077) : un GPU loué à l'heure, qui n'existe que pendant le travail. Un petit pour le développement, un gros pour les démos, jamais un allumé pour rien.
Les options y sont écrites noir sur blanc. Un H100 rend une vidéo deux à trois fois plus vite, pour à peu près le même coût par clip, mais chaque minute d'attente coûte presque trois fois plus cher. Pour le réseau, c'est le GPU qui appelle, à travers un relais : on a refusé d'exposer le courtier de messages sur Internet, un courtier géré et un VPN. Et pour les modèles, on a écarté ceux dont la licence limite les revenus ou l'usage commercial, même quand ils étaient bons.
Depuis, les pods ont un chien de garde, et une proposition est sur la table : des workers serverless qui ne coûtent rien au repos. Les erreurs qui y ont mené sont dans le billet sur les coûts.
Le Mac, lui, ne disparaît pas. Il redevient ce qu'il était au début, mais par choix : un exécuteur local. L'application de bureau, une fenêtre Tauri de quelques mégaoctets qui pilote la ligne de commande, doit pouvoir faire tourner des automatisations hors ligne. C'est en cours, je l'explique dans le billet sur les agents.
Ce qui garde le tout honnête
Rien de tout ça ne tiendrait sans tests. Les tests d'intégration lancent de vraies bases et un vrai courtier dans des conteneurs (Testcontainers), à partir d'une seule classe de base partagée. Les règles d'architecture sont vérifiées à chaque build. Un outil de réécriture automatique (OpenRewrite) passe en CI et échoue s'il trouve du code à moderniser. Et le critère le plus utile que j'aie écrit est simple : un pack qui vit dans un dossier hors du dépôt doit s'installer et tourner sans aucune modification du dépôt. La première fois, il a échoué quatre fois, sur quatre défauts que personne n'aurait vus de l'intérieur (ADR-049).
Ce qui reste difficile
CUDA et Apple Silicon. Le même modèle d'image tourne sur Metal sur le Mac et sur CUDA sur un GPU loué, avec le même moteur et la même recette. Mais c'est deux chemins à construire, deux images à tester, et la vidéo ne tient tout simplement pas sur le Mac.
La taille des poids. Un modèle vidéo de 14 milliards de paramètres pèse des dizaines de gigaoctets. Il faut les télécharger une fois, les garder quelque part, et ne pas les retélécharger à chaque démarrage.
Les démarrages à froid. Un GPU qui n'existe que pendant le travail doit démarrer, charger ses modèles, puis travailler. C'est ce qui rend l'à-la-demande moins cher, et plus lent pour la première tâche.
Le coût d'un GPU chaud. Le garder allumé rend tout plus rapide, et chaque minute d'attente se paie au prix d'une minute de calcul.
L'installation chez les autres. Une application signée et notarisée pour Mac, un paquet pour Linux, une version unique pour tout l'ensemble, des mises à jour qu'une petite firme sans informaticien peut faire seule. C'est écrit. Ce n'est pas encore livré.
Ce que vous pouvez en retenir
Si votre projet ne tourne que sur votre machine, commencez par retirer de votre code tout ce qui dépend d'elle : les noms de modèles, les adresses, les chemins. Découpez petit à petit, derrière une façade. Gardez les modèles près du matériel et le reste dans des conteneurs. Payez les GPU à l'usage, avec un chien de garde. Et écrivez un test qui vérifie, depuis l'extérieur, que quelqu'un d'autre peut vraiment s'en servir.
