Construire un langage de programmation depuis Abidjan, Côte d'Ivoire

Le projet de langage de programmation le plus ambitieux de 2026 ne vient pas de San Francisco, Berlin ou Tokyo. Il vient d'Abidjan -- la capitale économique de la Côte d'Ivoire, une ville de cinq millions d'habitants sur la côte sud de l'Afrique de l'Ouest.

La personne qui l'a lancé n'est pas un doctorant en théorie des langages de programmation. Il n'a pas travaillé chez Google sur V8, ni chez Mozilla sur Rust, ni chez Apple sur Swift. Son nom est Juste Thales Gnimavo, il est le CEO de ZeroSuite, et son CTO est une IA.

C'est l'histoire de la construction d'un langage de programmation avec un budget de 200 $/mois, aucune équipe d'ingénierie humaine et la conviction que la prochaine génération de développeurs n'apprendra pas à coder sur les outils que la Silicon Valley a construits pour elle-même.

Le bureau à Abidjan

Abidjan n'est pas une ville qui apparaît sur les listes des "hubs tech à surveiller". Ce n'est pas Nairobi avec son écosystème de startups établi. Ce n'est pas Lagos avec son flux de capital-risque. Ce n'est pas Le Cap avec sa proximité des marchés européens. Abidjan est une ville ouest-africaine francophone où l'industrie tech est naissante, où les communautés de développeurs sont petites et où les défis d'infrastructure sont réels.

L'internet tourne en moyenne entre 5 et 15 Mbps les bons jours. Les coupures de courant sont routinières -- pas quotidiennes, mais assez fréquentes pour que vous planifiiez autour d'elles. La climatisation est un luxe qui affecte la durée pendant laquelle vous pouvez travailler dans la chaleur de l'après-midi. Les données mobiles coûtent de l'argent réel, et un téléchargement de 1,5 Go représente une dépense significative.

C'est là que FLIN est né. Pas malgré ces contraintes, mais à cause d'elles.

Juste travaille depuis un bureau à Abidjan avec un MacBook, une connexion internet assez stable et un abonnement à Claude -- l'IA qui sert de CTO. Le budget mensuel pour l'ensemble du projet FLIN, incluant les coûts de calcul pour l'IA, les services cloud pour les tests et les dépenses accessoires, est d'environ 200 $.

Deux cents dollars. Par mois. Pour un langage de programmation avec un compilateur, une machine virtuelle, une base de données temporelle, un serveur HTTP, 409 fonctions intégrées, 180 composants d'interface embarqués et 3 452 tests qui passent.

Le modèle CEO + IA CTO

La sagesse conventionnelle dit que construire un langage de programmation nécessite une équipe d'ingénieurs compilateur expérimentés, des années de développement et un financement significatif. Le langage Rust a mis sept ans de sa conception à la 1.0, soutenu par les ressources de Mozilla. Swift a été développé par une équipe chez Apple. Go avait le soutien total de Google.

FLIN a deux personnes : un humain et une IA.

La division du travail n'est pas "l'humain conçoit, l'IA implémente". C'est plus nuancé que cela. Juste apporte l'expertise métier -- il comprend la douleur de construire des applications web en Afrique, il sait ce dont les développeurs des marchés émergents ont besoin, et il prend les décisions produit qui façonnent la conception de FLIN. Claude apporte l'exécution technique -- il écrit du code Rust, conçoit des structures de données, implémente des algorithmes et produit du logiciel correct à une vitesse qu'aucun développeur humain ne pourrait égaler seul.

Une session de développement typique ressemble à ceci :

Session 001 - 1er janvier 2026
Durée : ~45 minutes

Terminé :
- Création du Cargo.toml avec dépendances
- Création du squelette src/main.rs
- Création des répertoires de modules (lexer, parser, typechecker, codegen, vm, database, server, error)
- Définition des structs Position et Span
- Définition de l'enum Keyword (42 mots-clés)
- Définition de l'enum TokenKind (60+ types de tokens)
- Définition du struct Token
- Implémentation de Display pour les tokens
- Ajout de 25+ tests unitaires pour la recherche de mots-clés

Fichiers créés : 14
Lignes de Rust : ~1 000

Quarante-cinq minutes. Quatorze fichiers. Mille lignes de code Rust correct et testé. Ce n'est pas une ébauche -- ce sont des définitions de tokens de production qui alimentent encore le compilateur aujourd'hui, trois mois et 336 sessions plus tard.

La vitesse est possible grâce au fonctionnement du modèle d'IA CTO. Il n'y a pas de processus de revue de code qui prend trois jours. Il n'y a pas de phase "installer mon environnement de développement". Il n'y a pas de changement de contexte entre une conversation Slack sur l'architecture et un IDE où le code vit. Juste décrit ce qu'il veut, Claude le produit, et le compilateur Rust le vérifie. La boucle de retour est en minutes, pas en jours.

Mais la vitesse sans la qualité n'est que de l'échec rapide. Ce qui fait fonctionner le modèle, c'est le compilateur Rust comme troisième coéquipier. Quand Claude génère du code, cargo check vérifie immédiatement qu'il compile. cargo test vérifie qu'il se comporte correctement. cargo clippy vérifie qu'il suit les idiomes Rust. L'IA produit le code ; le compilateur le valide ; l'humain prend les décisions architecturales. Trois rôles, deux entités, zéro cycle perdu.

La contrainte des 200 $/mois

La contrainte budgétaire n'est pas une histoire de difficultés. C'est une contrainte de conception -- et comme toutes les bonnes contraintes de conception, elle produit de meilleurs résultats.

Quand vous avez 200 $/mois, vous ne pouvez pas vous permettre :

• L'infrastructure cloud pour la CI/CD. Donc la suite de tests doit tourner localement, vite. Les 3 452 tests de FLIN se complètent en moins de 30 secondes sur un MacBook.
• Une équipe de prestataires ou de freelances. Donc chaque morceau de code doit être écrit par l'équipe de deux personnes. Pas de sous-traitance des parties ennuyeuses.
• Plusieurs environnements de développement. Donc la chaîne d'outils doit être simple. Rust, Cargo, un terminal. Pas d'orchestration Docker pour le développement, pas de cluster Kubernetes, pas d'environnement de staging.
• Des API payantes pour les fonctionnalités de base. Donc la base de données (FlinDB) est embarquée, le serveur HTTP est intégré et le compilateur est autonome. Les coûts d'API externes sont limités aux appels de la passerelle IA, qui sont refacturés à l'utilisateur final.

Ces contraintes ont façonné l'architecture de FLIN de manières qui bénéficient à chaque utilisateur :

• FlinDB est embarqué parce que nous ne pouvions pas nous permettre une instance PostgreSQL managée pour le développement. Le résultat est que les utilisateurs de FLIN n'ont pas non plus besoin d'une base de données managée -- ça fonctionne, directement, sans configuration.
• La distribution en binaire unique existe parce que nous ne pouvions pas nous permettre les coûts de CDN pour une distribution multi-fichiers. Le résultat est que FLIN s'installe en une seule commande, partout dans le monde.
• Les 409 fonctions intégrées existent parce que nous ne pouvions pas nous permettre de dépendre de paquets npm (et du runtime Node.js qu'ils nécessitent). Le résultat est que FLIN a zéro dépendance externe à l'exécution.

Ce qui a commencé comme une limitation budgétaire est devenu un avantage produit. Les meilleurs outils sont souvent construits sous des contraintes qui forcent la simplicité.

Pourquoi l'Afrique compte

FLIN aurait pu être construit pour résoudre les problèmes des développeurs de San Francisco. Ces problèmes sont réels -- la complexité des chaînes d'outils, la fatigue JavaScript, l'enfer de la configuration. Mais les problèmes sont surmontables. Un développeur à San Francisco a un internet rapide, une alimentation illimitée, du calcul bon marché et un employeur qui paie pour les outils.

Les problèmes sont existentiels en Afrique.

Quand télécharger node_modules coûte le budget de données mobiles d'une journée, le développeur ne télécharge pas node_modules. Il n'apprend pas React. Il ne construit pas d'applications web. Il est exclu de l'économie logicielle mondiale -- non par manque de talent ou de motivation, mais par les outils eux-mêmes.

Le modèle "zéro dépendance, binaire unique" de FLIN n'est pas un luxe pour les développeurs africains. C'est un prérequis pour la participation. Un développeur à Dakar, Douala ou Dar es-Salaam peut télécharger un binaire de 15 Mo, créer un fichier .flin et commencer à construire. Pas de npm. Pas de téléchargement de 1,5 Go. Pas de chaîne d'outils complexe. Pas de barrière entre "je veux construire quelque chose" et "je suis en train de construire quelque chose".

Le nom FLIN lui-même reflète cette orientation. Il vient du fongbé, une langue parlée au Bénin :

E flin nu
|  |   |
|  |   +-- "choses" / "trucs"
|  +------ "se souvenir" / "ne pas oublier"
+--------- "il/elle" (3e personne)

Traduction : "Il se souvient des choses"

L'éléphant est le symbole de FLIN parce que dans la culture fongbé, les éléphants représentent la mémoire et la sagesse. "Les éléphants n'oublient jamais" -- comme la base de données temporelle de FLIN, qui maintient l'historique complet de chaque enregistrement. Et l'éléphant est un symbole de l'Afrique, où le langage a été conçu.

Ce n'est pas performatif. Le nom, le symbole et la philosophie de conception sont enracinés dans le même endroit : la conviction que le prochain milliard de développeurs viendra d'Afrique, d'Asie et d'Amérique latine, et qu'ils méritent des outils construits pour leur réalité.

Le journal de sessions : 336 sessions et ça continue

Chaque session de développement FLIN est journalisée. La session 001 était le 1er janvier 2026 -- mise en place du projet et définitions de tokens. La session 336 était la plus récente, complétant les migrations de base de données et le diffing de schéma. Entre ces deux bornes, l'histoire complète du développement d'un langage de programmation est documentée.

Les journaux de sessions révèlent une cadence de développement qu'aucune équipe traditionnelle ne pourrait soutenir :

Janvier 2026 :    Sessions 001-090    Lexer, parser, AST, fondations du vérificateur de types
Février 2026 :    Sessions 091-250    Générateur de code, VM, FlinDB, serveur HTTP,
                                      fonctions natives
Mars 2026 :       Sessions 251-336    Composants d'interface, framework de test, migrations,
                                      Stripe, webhooks, préparation production

Trois cent trente-six sessions en 85 jours. Une moyenne de quatre sessions par jour. Chaque session concentrée, documentée et produisant du code testé. Le modèle d'IA CTO permet cette cadence parce que Claude ne se fatigue pas, ne perd pas le contexte entre les sessions (au sein d'une conversation) et n'a pas besoin de pauses café.

Mais Juste se fatigue. L'humain dans la boucle est le goulot d'étranglement -- pas dans la production de code, mais dans la prise de décision. Choisir si FlinDB devrait utiliser des B-trees ou des LSM trees. Décider si l'opérateur @ devrait fonctionner sur les instances d'entité ou les résultats de requête. Déterminer si le système d'import de FLIN devrait utiliser des chemins de système de fichiers ou des noms de modules. Ce sont des décisions produit qui nécessitent de comprendre l'utilisateur, le marché et la vision.

L'IA produit le code. L'humain produit la direction. Aucun ne peut faire le travail de l'autre.

La chaîne d'outils : délibérément simple

L'environnement de développement de FLIN est :

• Un MacBook.
• Rust (installé via rustup).
• Un terminal (iTerm2).
• Claude (via API et CLI).
• Git (pour le contrôle de version).

Il n'y a pas d'IDE avec des extensions spécifiques au langage. Il n'y a pas de Docker pour la base de données de développement (FlinDB est embarqué). Il n'y a pas de pipeline CI/CD (les tests tournent localement). Il n'y a pas d'environnement de staging (le binaire est le même partout). Il n'y a pas d'outil de gestion de projet au-delà des fichiers Markdown dans le dépôt.

Cette simplicité est un choix, pas une limitation. Chaque outil que vous ajoutez à un workflow de développement crée de la charge de maintenance, nécessite de la configuration et introduit des points de défaillance potentiels. Quand votre équipe est deux entités et votre budget est de 200 $/mois, chaque outil inutile est un ennemi.

Le processus de build est :

bashcargo build --release    # Compiler le compilateur + runtime FLIN
cargo test               # Lancer 3 452 tests
cargo clippy -D warnings # Lint pour les idiomes Rust et bugs potentiels

Trois commandes. Si les trois passent, le code est prêt. Pas de pipeline Jenkins. Pas de workflow GitHub Actions. Pas de sessions de débogage "les tests passent en local mais échouent en CI".

Ce qu'Abidjan nous a appris sur la conception de langage

Vivre à Abidjan n'a pas seulement contraint le budget de FLIN. Cela a façonné la philosophie de conception de FLIN.

Hors-ligne d'abord n'est pas un cas limite. À Abidjan, la connectivité internet est intermittente. FlinDB est embarqué spécifiquement pour que les applications FLIN fonctionnent sans connexion internet. La base de données est locale. Le compilateur est local. Le serveur est local. Si l'internet tombe, vous pouvez toujours développer, tester et faire tourner votre application.

La simplicité est une fonctionnalité, pas une limitation. Quand vos utilisateurs incluent des développeurs autodidactes en Afrique francophone qui ont appris le HTML à partir de vidéos YouTube sur téléphone mobile, vous ne pouvez pas vous permettre une courbe d'apprentissage raide. La syntaxe de FLIN est conçue pour que quelqu'un qui connaît le HTML et l'assignation basique de variables puisse construire une vraie application. Les mots-clés entity, save, delete et for ont été choisis parce qu'ils se lisent comme de l'anglais (et se transposent intuitivement en français : entité, sauvegarder, supprimer, pour).

La taille du binaire compte. Un binaire de 15 Mo se télécharge en secondes sur une connexion lente. Une chaîne d'outils de 1,5 Go ne se télécharge pas du tout. La distribution en binaire unique de FLIN n'est pas une prouesse technique -- c'est une exigence d'accessibilité.

Le temps du développeur est la ressource la plus rare. Dans la Silicon Valley, le temps du développeur est cher parce que les salaires sont élevés. À Abidjan, le temps du développeur est cher parce qu'il y a si peu de développeurs. Dans les deux cas, un outil qui gaspille le temps du développeur en configuration, gestion de dépendances et code boilerplate est un outil qui trahit ses utilisateurs. Le modèle zéro-configuration, zéro-dépendance de FLIN respecte le temps du développeur peu importe où il se trouve.

Le pari plus large : le logiciel depuis la périphérie

FLIN fait partie de ZeroSuite, une entreprise qui construit six produits logiciels depuis Abidjan avec zéro ingénieur humain. La thèse est audacieuse : que le modèle CEO + IA CTO peut produire du logiciel qui rivalise avec -- et dans certains cas surpasse -- les produits construits par des équipes bien financées dans les hubs tech traditionnels.

Les produits sont :

• Déblo.ai -- Une plateforme éducative IA pour les élèves africains, du primaire au baccalauréat.
• Déblo Pro -- Un assistant IA professionnel pour les comptables SYSCOHADA, avocats et auditeurs.
• sh0.dev -- Une plateforme PaaS en binaire unique pour les déploiements auto-hébergés, écrite en Rust.
• FLIN -- Un langage de programmation memory-native.
• ZeroCore -- Le moteur de base de données embarqué qui alimente FlinDB.
• ThalesAndHisAiCtoClaude.com -- Le blog que vous lisez, documentant le voyage.

Six produits. Un humain. Une IA. Deux cents dollars par mois.

Ce n'est pas une preuve de concept. Déblo.ai a de vrais élèves. sh0.dev a de vrais déploiements. FLIN a 3 452 tests qui passent et 409 fonctions qui fonctionnent. Le modèle fonctionne.

Il fonctionne parce que l'IA a fondamentalement changé ce qui est possible pour un fondateur solo. Des tâches qui nécessitaient autrefois une équipe -- écrire un lexer, implémenter un vérificateur de types, construire un moteur de base de données, créer un pipeline de déploiement -- peuvent maintenant être accomplies par une seule personne dirigeant une IA avec des capacités et un contexte suffisants.

Et ça fonctionne depuis Abidjan parce que l'internet est mondial. Claude ne se soucie pas de savoir si le terminal auquel il se connecte est à San Francisco ou en Côte d'Ivoire. Le compilateur Rust produit le même binaire quel que soit le fuseau horaire du développeur. Cargo télécharge les crates à la même vitesse depuis crates.io que la requête vienne de Mountain View ou de Marcory.

L'avantage géographique des hubs tech traditionnels -- la proximité des talents, des investisseurs et des clients -- compte de moins en moins chaque année. Le talent est l'IA. L'investissement est de 200 $/mois. Les clients sont mondiaux.

La suite

La feuille de route de FLIN vers la v1.0 est documentée dans l'article précédent de cette série. Les jalons techniques sont clairs : système de plugins, imports multi-fichiers, optimisation des performances et finalement l'auto-hébergement -- le moment où FLIN pourra se compiler lui-même.

Mais le jalon qui compte le plus n'est pas technique. C'est le moment où un développeur à Lomé, Cotonou ou Ouagadougou télécharge le binaire FLIN, crée son premier fichier .flin et construit quelque chose de réel. Quelque chose qui résout un problème dans sa communauté. Quelque chose qui aurait été inaccessible derrière le mur de npm, React, TypeScript et 1 847 dépendances.

C'est pourquoi nous construisons FLIN depuis Abidjan. Pas parce que c'est l'endroit évident pour construire un langage de programmation. Parce que c'est l'endroit nécessaire. Les contraintes de cette ville -- l'internet lent, les coupures de courant, les budgets limités, les petites communautés de développeurs -- sont les contraintes que des milliards de personnes partagent. Un langage conçu pour ces contraintes est un langage conçu pour le monde.

Chaque langage de programmation majeur a été construit par une équipe dans une entreprise bien financée d'un pays riche. FLIN est construit par un fondateur en Afrique de l'Ouest et une IA, avec un budget qui ne couvrirait pas la facture mensuelle de café d'un seul ingénieur à San Francisco.

Si ça fonctionne -- et 3 452 tests qui passent suggèrent que c'est possible -- ça prouve quelque chose de plus grand qu'un langage. Ça prouve que l'ère du verrouillage géographique dans le logiciel touche à sa fin. Que les outils de création ne sont plus réservés à ceux qui ont la chance de vivre près de Sand Hill Road. Que le prochain Rust, le prochain Go, le prochain Swift pourrait venir d'Abidjan, d'Accra ou d'Addis-Abeba.

E flin nu. Il se souvient des choses.

Et peut-être que la chose la plus importante dont il se souvient est que de grands logiciels peuvent venir de n'importe où.

Ceci est la partie 10 de la série "Comment nous avons construit FLIN", qui documente comment un CEO à Abidjan et une IA CTO ont construit un langage de programmation en partant de zéro.

Navigation de la série : - [6] Pourquoi nous avons choisi Rust pour construire un langage de programmation - [7] Écrire des applications comme en 1995 avec la puissance de 2026 - [8] FLIN en pratique : premiers exemples - [9] La feuille de route vers FLIN v1.0 - [10] Construire un langage de programmation depuis Abidjan, Côte d'Ivoire (vous êtes ici)