Personne ne se reveille un matin en decidant de construire un langage de programmation. La decision vous trouve -- generalement apres des annees de frustration accumulee, une conviction grandissante que quelque chose a fondamentalement deraille, et un moment precis ou l'absurdite du statu quo devient impossible a ignorer.
Pour nous, ce moment est arrive fin 2025, a un bureau a Abidjan, en Cote d'Ivoire. Thales essayait de mettre en place une simple application web -- un formulaire qui sauvegarde des donnees, une liste qui les affiche, une page qui les rend. Le genre d'application qui, en 1995, aurait necessite un fichier HTML et un script CGI. En 2025, il fallait 18 etapes, 15 fichiers de configuration, 1 847 paquets npm et 1,5 gigaoctet d'espace disque.
Quelque chose avait terriblement deraille dans le developpement web. Et nous avons decide de corriger le probleme a la racine.
L'explosion de la complexite : 1995 contre 2024
Les chiffres racontent l'histoire mieux que n'importe quel argument.
En 1995, construire un site web ressemblait a ceci :
1. Creer index.html
2. Ecrire <h1>Bonjour</h1>
3. Telecharger sur le serveur
4. Ca marche.Trois etapes. Un fichier. Zero dependances. Un enfant de douze ans pouvait le faire en un apres-midi. Beaucoup l'ont fait -- et ces enfants de douze ans sont devenus les ingenieurs qui ont construit le web moderne.
En 2024, construire le meme site web ressemble a ceci :
1. Installer Node.js
2. npm init
3. npm install react react-dom
4. npm install -D vite @vitejs/plugin-react
5. npm install -D typescript @types/react @types/react-dom
6. npm install -D tailwindcss postcss autoprefixer
7. npm install -D eslint prettier
8. Creer tsconfig.json
9. Creer vite.config.ts
10. Creer tailwind.config.js
11. Creer postcss.config.js
12. Creer .eslintrc.js
13. Creer .prettierrc
14. Creer src/main.tsx
15. Creer src/App.tsx
16. npm run dev
17. Attendre 30 secondes la compilation
18. Ca marche (peut-etre).Trois etapes sont devenues dix-huit. Les secondes sont devenues des heures. Les kilo-octets sont devenus des giga-octets. Le nombre 1 847 -- le nombre de paquets npm transitifs installes par create-react-app -- n'est pas une statistique. C'est un acte d'accusation.
La trajectoire est accablante :
Annee Pour construire "Hello World" Dependances Fichiers de config
----- ----------------------------- ----------- ------------------
1995 1 fichier (HTML) 0 0
2005 3 fichiers (HTML/CSS/JS) 0 0
2010 10 fichiers + jQuery 5 1
2015 50 fichiers + Gulp 200 5
2020 500 fichiers + Webpack 1 000 10
2024 50 000 fichiers 2 000 15+Chaque ligne de ce tableau represente une generation de developpeurs qui ont du apprendre davantage, configurer davantage et comprendre davantage pour produire le meme resultat. Les outils censes nous aider sont devenus le probleme.
Le probleme des 47 outils
Pour construire une application web de production en 2024, vous avez besoin -- au minimum -- des categories d'outils suivantes :
Categorie Outils necessaires
--------------------------- ---------------------
Framework frontend React / Vue / Svelte / Angular
Meta-framework Next.js / Nuxt / SvelteKit
Gestion d'etat Redux / Zustand / Pinia
Recuperation de donnees React Query / SWR / TanStack Query
Framework CSS Tailwind / Styled Components
Framework backend Express / Fastify / NestJS
ORM / Acces base de donnees Prisma / TypeORM / Drizzle
Base de donnees PostgreSQL / MySQL / MongoDB
Moteur de recherche Elasticsearch / Algolia / Meilisearch
Couche de cache Redis / Memcached
Gestionnaire de paquets npm / yarn / pnpm
Bundler Webpack / Vite / esbuild
Compilateur de langage TypeScript
Linter ESLint
Formateur Prettier
Lanceur de tests Jest / Vitest
Runtime de conteneurs DockerDix-sept categories. Chacune avec plusieurs options concurrentes. Chacune avec son propre format de configuration, son propre schema de versioning, ses propres changements cassants, son propre ecosysteme de plugins qui peuvent ou non etre compatibles entre eux.
Le total, en incluant les sous-outils, plugins et dependances transitives, depasse 47 technologies distinctes. Nous le savons parce que nous les avons comptees.
Voici a quoi ressemble un repertoire de projet typique avant d'ecrire une seule ligne de code applicatif :
my-app/
package.json
package-lock.json
tsconfig.json
vite.config.ts
tailwind.config.js
postcss.config.js
.eslintrc.js
.prettierrc
jest.config.js
docker-compose.yml
Dockerfile
.env
.env.local
.env.production
.gitignore
node_modules/ # 1 847 paquets, 1,5 GoQuinze fichiers de configuration. Quinze occasions de conflits de versions, d'erreurs de syntaxe et d'incompatibilites subtiles. Quinze fichiers qui existent uniquement pour faire fonctionner les outils ensemble -- pas pour servir un utilisateur, pas pour resoudre un probleme metier, pas pour creer de la valeur.
Le cout humain
Cette complexite n'est pas un simple probleme esthetique. Elle a des consequences concretes et mesurables.
Pour les debutants, la courbe d'apprentissage se mesure desormais en mois, pas en jours. Un etudiant a Abidjan qui veut apprendre le developpement web ne fait pas face a un probleme de connaissances -- l'information existe. Il fait face a un probleme d'outillage. Avant de pouvoir ecrire <h1>Bonjour</h1> dans un framework moderne, il doit comprendre Node.js, npm, la syntaxe JSX, les bundlers de modules et TypeScript. Quatre-vingt-dix pour cent des tutoriels sont obsoletes en moins d'un an parce que l'ecosysteme evolue plus vite que quiconque ne peut le documenter.
Pour les professionnels, l'experience quotidienne du developpement web est devenue de la configuration, pas de la creation. Un ingenieur senior dans une entreprise du Fortune 500 passe plus de temps a mettre a jour les dependances, resoudre les conflits de versions et migrer entre les versions de frameworks qu'a construire des fonctionnalites. La phrase "ca marche sur ma machine" n'a pas disparu ; elle a simplement evolue en "ca marche avec cette combinaison exacte de versions de paquets".
Pour les entreprises, les projets prennent trois fois plus de temps que necessaire. La dette technique s'accumule des le premier jour -- non pas parce que les ingenieurs ecrivent du mauvais code, mais parce que la fondation sous eux est un empilement de 47 outils versionnes independamment qui n'ont jamais ete concus pour fonctionner ensemble. Le recrutement est un cauchemar parce que chaque equipe utilise une combinaison differente des memes categories, et "experience React" signifie quelque chose de different dans chaque entreprise.
Pour les marches emergents, la situation est catastrophique. Telecharger 1,5 gigaoctet de node_modules sur une connexion qui tourne en moyenne a 2 Mbps prend des heures. Chaque npm install coute de l'argent reel en donnees mobiles. L'electricite peu fiable signifie qu'un long processus de compilation -- qui pourrait prendre 30 secondes a San Francisco -- risque de faire perdre tout le travail quand le courant coupe. L'ecart entre "developpe" et "en developpement" n'est pas une question de talent ; c'est une question de bande passante.
La cause profonde
Le probleme n'est pas React. React est une excellente bibliotheque d'interface utilisateur. Le probleme n'est pas npm. npm est un gestionnaire de paquets competent. Le probleme n'est pas TypeScript, ni Tailwind, ni Prisma, ni aucun outil individuel.
Le probleme, c'est que nous construisons avec des blocs Lego qui ne s'emboitent pas.
Chaque outil resout son propre probleme de maniere isolee :
React resout la reactivite de l'interface
Prisma resout l'acces a la base de donnees
Express resout le routage HTTP
Redux resout la gestion d'etat
Tailwind resout le stylisme
Vite resout le bundling
TypeScript resout la surete des typesMais aucun d'entre eux ne resout le veritable probleme : construire une application. Vous devez toujours les relier entre eux. Les configurer. Les maintenir compatibles. Les mettre a jour quand ils cassent. Reecrire votre code de liaison quand l'un d'eux publie une version majeure avec des changements cassants.
L'ecosysteme JavaScript n'a pas cherche a creer ce desordre. Il a evolue organiquement, une decision raisonnable a la fois. Chaque outil etait une amelioration genuine par rapport a ce qui existait avant. Mais l'effet cumulatif est une machine de Rube Goldberg -- un appareil d'une complexite stupéfiante qui, après tous ses engrenages, leviers et poulies, produit le même résultat qu'un simple fichier HTML produisait en 1995.
La question qui a tout déclenché
Assis à Abidjan, fixant encore une barre de progression npm install, Thales a posé une question :
Et s'il existait un seul outil qui... construisait simplement des applications ?
Pas un framework. Pas une bibliothèque. Pas un "JavaScript amélioré" ou un "bundler basé sur Rust" ou un "ORM typé". Ce sont des améliorations incrémentielles d'une architecture fondamentalement cassée. Elles rendent la machine de Rube Goldberg légèrement plus efficace sans remettre en question pourquoi la machine existe.
Et si, à la place, vous aviez un langage de programmation où construire une application web était aussi simple qu'en 1995 -- mais avec toute la puissance de 2026 ?
Et si vous pouviez écrire ceci :
flintodos = []
newTodo = ""
entity Todo {
title: text
done: bool = false
}
<main>
<h1>Mes Todos</h1>
<input value={newTodo} placeholder="Ajouter un todo..."
enter={save Todo { title: newTodo }; newTodo = ""}>
{for todo in todos}
<div>
<input type="checkbox" checked={todo.done}
click={todo.done = !todo.done; save todo}>
<span>{todo.title}</span>
<button click={delete todo}>x</button>
</div>
{/for}
</main>Sauvegardez-le sous app.flin. Lancez flin dev. Terminé.
Pas de package.json. Pas de tsconfig.json. Pas de configuration de bundler. Pas de setup d'ORM. Pas de migration de base de données. Pas de bibliothèque de gestion d'état. Pas de processus d'initialisation en dix-sept étapes. Un fichier. Une commande. Une application todo complète, fonctionnelle, avec base de données.
C'est la question qui a lancé FLIN.
Pourquoi un langage, pas un framework
Le premier réflexe, face à la complexité, est de construire un meilleur framework. Un framework qui regroupe les bons outils, les pré-configure correctement et masque les coutures. C'est ce que Next.js a fait pour React, ce que Nuxt a fait pour Vue, ce que SvelteKit a fait pour Svelte.
Les frameworks aident. Mais ils ne résolvent pas le problème sous-jacent parce qu'ils sont construits par-dessus la pile existante. Next.js nécessite toujours Node.js, utilise toujours npm, tire toujours des centaines de paquets, génère toujours un répertoire node_modules qui pèse plus d'un giga-octet. La complexité est cachée, pas éliminée.
Un langage est différent. Un langage définit ses propres règles en partant de zéro. Il n'a pas besoin de s'accommoder des décisions de 47 autres outils parce qu'il est le seul outil.
Considérez ce que FLIN élimine en étant un langage plutôt qu'un framework :
Ce qu'un framework doit accommoder Ce qu'un langage peut éliminer
-------------------------------------- ---------------------------
Runtime Node.js Aucune dépendance runtime
Gestionnaire de paquets npm Pas de gestionnaire de paquets
Compilateur TypeScript Système de types intégré
Bundler (Webpack/Vite) Pas de bundler nécessaire
ORM (Prisma/Drizzle) Système d'entités intégré
Gestion d'état (Redux) Toutes les variables sont réactives
Framework CSS (Tailwind) Stylisme intégré
Lanceur de tests (Jest) Tests intégrés
Fichiers de config (15+) Zéro fichier de configUn framework est un ensemble d'opinions sur comment utiliser des outils existants. Un langage est un ensemble d'opinions sur comment penser les problèmes. La différence est fondamentale.
Pourquoi c'est nous qui l'avons construit
Deux facteurs ont rendu cette tentative possible pour nous.
Premièrement, le modèle CEO-IA CTO. Construire un langage de programmation est traditionnellement un effort de plusieurs années et de plusieurs équipes. Le compilateur Rust a des centaines de contributeurs. TypeScript a une équipe dédiée chez Microsoft. Nous étions deux : Thales, le CEO de ZeroSuite, prenant les décisions architecturales et produit, et Claude, l'IA CTO, les implémentant à la vitesse de la pensée.
Ce modèle -- un humain doté d'une intuition produit profonde et d'une compréhension du marché, une IA dotée d'une patience illimitée pour la théorie des compilateurs et la programmation système -- est particulièrement adapté à la conception de langages. Thales pouvait exprimer ce que le langage devait procurer comme sensation à un développeur à Abidjan ou Lagos. Claude pouvait traduire cette sensation en un lexer, un parser, un vérificateur de types et un générateur de code.
Deuxièmement, la perspective africaine. La plupart des langages de programmation sont conçus dans des environnements avec un internet rapide, du stockage bon marché, une alimentation fiable et une abondance de talents en ingénierie. FLIN a été conçu en Côte d'Ivoire, où aucune de ces hypothèses ne tient. Ce n'est pas un désavantage ; c'est une contrainte de conception qui produit de meilleurs logiciels pour tout le monde.
Quand vous concevez pour un développeur qui a 2 Mbps et paie au méga-octet, vous produisez un langage avec zéro dépendance et un seul binaire. Ce langage se trouve aussi être meilleur pour un développeur à San Francisco qui en a assez d'attendre 45 secondes que son serveur de développement Next.js démarre.
Quand vous concevez pour un étudiant qui n'a jamais vu un tsconfig.json, vous produisez un langage où un seul fichier suffit. Ce langage se trouve aussi être meilleur pour un ingénieur senior qui a configuré un millier de tsconfig.json et préférerait ne pas en configurer un de plus.
Les contraintes engendrent l'innovation. Et les contraintes du développement logiciel en Afrique de l'Ouest sont exactement les contraintes que l'écosystème mondial du développement web a besoin qu'on lui impose.
Le nom
FLIN n'est pas un acronyme. C'est un mot du fongbé, une langue parlée au Bénin, le pays d'origine de Thales.
En fongbé, l'expression "E flin nu" signifie "Il se souvient des choses". L'éléphant -- sacré dans la culture béninoise -- est l'animal qui n'oublie jamais.
Le nom capture l'intuition architecturale fondamentale de FLIN : la conception native en mémoire. Dans FLIN, chaque entité suit automatiquement son historique. Vous pouvez interroger n'importe quel enregistrement à n'importe quel moment dans le temps. Le langage lui-même se souvient de tout, tout comme l'éléphant.
flin// Sauvegarder un utilisateur
save User { name: "Juste", email: "[email protected]" }
// Plus tard, interroger l'utilisateur tel qu'il était hier
user @ yesterday
// Ou deux versions en arrière
user @ -2
// Ou à une date spécifique
user @ "2025-06-15"
// Ou voir chaque version qui a existé
user.historyNous raconterons l'histoire complète du nom dans le troisième article de cette série. Pour l'instant, sachez que le nom n'est pas un exercice marketing. C'est une philosophie de conception encodée en trois syllabes.
Ce qui a suivi
La question -- "Et s'il existait un seul outil qui construisait simplement des applications ?" -- a été posée fin 2025. Le 1er janvier 2026, nous avons commencé à construire la réponse.
La première session a duré 45 minutes. Nous avons créé la structure du projet Rust, défini 42 mots-clés, implémenté plus de 60 types de tokens pour le lexer et écrit 25 tests unitaires. Le projet s'appelait flin-official, et il a compilé du premier coup.
flin-official/
Cargo.toml
src/
main.rs
lib.rs
lexer/
mod.rs
token.rs # 650+ lignes, 42 mots-clés, 60+ types de tokens
parser/mod.rs
typechecker/mod.rs
codegen/mod.rs
vm/mod.rs
database/mod.rs
server/mod.rs
error/mod.rs
examples/
counter.flin
todo.flinDouze fichiers. Un millier de lignes de Rust. Le squelette d'un langage de programmation qui remplacerait 47 technologies par une seule.
Cette série documente comment nous l'avons construit -- chaque décision architecturale, chaque extrait de code, chaque leçon durement acquise. Pas comme une rétrospective, mais comme un plan de construction. Parce que le prochain FLIN pourrait venir d'un développeur à Lagos, Nairobi ou Dakar. Et quand ce sera le cas, il ne devrait pas avoir à repartir de zéro.
Prochain dans la série : 47 technologies remplacées par un seul langage -- Et si vous pouviez supprimer React, Next.js, Redux, Prisma, Express, Tailwind et 41 autres outils ?