Série Scalabilité - Partie 1

Introduction

Je suis un grand fan de l'histoire des sciences. Je peux en parler pendant des heures et je dévore podcasts et vidéos sur le sujet.

Prenez le problème à trois corps : comment trois objets célestes interagissent-ils gravitationnellement, et peut-on prédire précisément leurs trajectoires ? Spoiler : non. Pas de solution analytique générale. Henri Poincaré, en s'y frottant, a découvert ce qu'on appelle aujourd'hui le chaos déterministe, ouvrant une porte vers la théorie du chaos.

Quel rapport avec l'IA ? Imaginez un système composé de trois entités -- un serveur, un engine IA et une interface utilisateur -- qui doivent coopérer pour fonctionner. Un peu comme des astres gravitationnellement liés : chacun a son rôle, chacun dépend des deux autres. Mais gare au moindre déséquilibre.

Ce "système à 3 corps" (serveur, moteur IA, interface) est une métaphore -- et un vrai projet -- pour repenser les architectures d'IA : distribuées, robustes, durables.

On n'est pas obligés d'en appeler à la théorie du chaos... encore que, vous verrez : rendre ce système résilient, c'est tout sauf trivial.

Penser l'IA comme un écosystème

Dans cette série d'articles, je vous présente un prototype d'IA distribuée en Rust, qui va bien au-delà d'un simple appel API vers un serveur vLLM ou Ollama.

Ce système est une brique essentielle de mAIstrow : une plateforme d'IA générative conçue pour redonner le contrôle aux utilisateurs, avec un souci de souveraineté numérique et d'efficacité énergétique. Au cœur de cette approche : Rust, Go, et des architectures distribuées pensées pour durer.

Pourquoi ne pas se contenter d'un serveur d'IA classique ?

Aujourd'hui, beaucoup de projets IA se reposent sur des appels HTTP vers un serveur centralisé. C'est pratique, mais ça a ses limites :

• Fragilité : une simple coupure réseau ou un serveur qui plante, et c'est la catastrophe.
• Dépendance : aux API externes, aux clouds américains, à des modèles opaques.
• Complexité : difficile de gérer proprement plusieurs utilisateurs, requêtes simultanées, files d'attente...

Même des workflows avancés (comme avec n8n) peuvent se casser les dents s'ils ne reposent pas sur une architecture bien distribuée.

La réponse ? Concevoir un système intelligent, résilient et pensé pour la montée en charge. Pas juste un backend un peu solide : un véritable écosystème.

Le système à 3 corps : anatomie d'une architecture Rust

Voici les 3 composants du système, chacun jouant sa partition :

Serveur (écrit en Rust dans le proto, Go en prod)

• Gère les connexions WebSocket
• Persiste les données (SQLite)
• Répartit les tâches avec un algo simple (round-robin)
• Garantit la livraison même si un client se déconnecte

Engine IA (client Rust)

• Réceptionne et traite les requêtes (ex. : découper une phrase mot par mot)
• Reprend une tâche interrompue grâce à la persistance
• Optimisé pour tourner avec peu de ressources

Interface utilisateur (web minimaliste)

• Permet d'envoyer une requête
• Reçoit les réponses en streaming
• Utilise un UUID local pour la persistance de session

Le flux est simple en apparence : l'utilisateur envoie une requête, le serveur la dispatche à un engine, l'engine traite et streame la réponse.

Facile, non ? Sur le papier, oui. Mais quand un de ces composants tombe ? Quand il faut prioriser des centaines de requêtes ? Quand une tâche est annulée en cours de traitement ?

C'est là qu'il faut penser résilience, scalabilité et sobriété énergétique. Et croyez-moi : ça commence dès la conception des protocoles.

Les fondations de mAIstrow : Rust, sobriété et abstraction

Ce prototype n'est pas un exercice gratuit : il fonde les bases de mAIstrow, une plateforme d'IA souveraine, distribuée et performante. On y fait tourner les moteurs localement, sans API tierce. Moins d'énergie, plus de contrôle.

Rust offre ici un vrai terrain de jeu, grâce à :

• Des traits pour modéliser protocoles, tâches et persistance
• La programmation asynchrone
• Des optimisations SIMD
• Une rigueur qui pousse à penser chaque détail

On peut ainsi abstraire le code métier des couches de transport et de persistance. L'algorithmique reste claire, le système reste souple.

Une philosophie d'ingénierie holistique

Ce projet est aussi le reflet d'un parcours : de mes débuts sur un ZX81 à 6 ans, à mes contributions à Plan 9, en passant par des libraries trigonométriques pour l'aérospatial en assembleur SPARC V7, ou encore un bug résolu dans 9vx avec Ron Minnich lui-même.

J'ai appris que l'innovation naît de la simplicité et de la bonne abstraction.

Avec DREMML, je veux transmettre cette vision : créer des systèmes qui allient robustesse technique, empathie utilisateur et durabilité. Former, accompagner, construire du long terme.

Et maintenant ?

Le système à 3 corps montre qu'on peut repenser l'IA autrement : comme un écosystème distribué, résilient et souverain. C'est un début. La suite arrive.

À venir dans les prochains épisodes

• Partie 2 : Explorer les frameworks distribués comme Apache Kafka, Pulsar, Redpanda et Ray.
• Partie 3 : Architecture async avec Rust -- async traits, ergonomie, pièges et performances.
• Partie 4 : Résilience, montée en charge, sobriété.
• Partie 5 : Chaos Engineering -- on fait tout péter, pour mieux reconstruire.
• Partie 6 : Mesures de performances (Valgrind, flamegraphs, etc.).
• Partie 7 (peut-être) : Comparaison Rust / Go / Node.js / Python (oui, malgré le GIL).

Glossaire rapide

• SIMD : Single Instruction, Multiple Data. Instructions parallèles très utiles pour optimiser les performances.
• GIL (Python) : Global Interpreter Lock. Empêche l'exécution parallèle de threads en Python pur.
• Plan 9 : OS expérimental des créateurs d'Unix. Abstractions puissantes, réseau natif.
• Chaos déterministe : Un système entièrement déterministe peut avoir un comportement imprévisible à long terme, à cause d'une forte sensibilité aux conditions initiales.