L’ouverture du compilateur Mojo est le moment que beaucoup de développeurs attendaient. Le 18 août 2026, Modular a annoncé que le langage, le compilateur et les outils Mojo sont publiés en open source sous Apache 2.0 avec exceptions LLVM. Le code est arrivé dans modular/modular via la PR #6904, avec plus de 561 000 lignes ajoutées et 2 853 fichiers modifiés. Cela arrive une semaine après Mojo 1.0, présenté comme une base stable.

Pipeline abstrait de compilateur ouvert avec cadenas ouvert et puces génériques

Pour Open Source Radar, ce n’est pas une annonce de langage ordinaire. Mojo attire parce qu’il promet une ergonomie proche de Python avec des performances système, SIMD, GPU et accélérateurs AI. Il était aussi facile à écarter: le compilateur restait fermé. Pour des mainteneurs open source, des laboratoires ou des entreprises en revue sécurité, c’était un blocage sérieux. Ce blocage diminue. Le vrai test commence: Mojo peut-il devenir un projet ouvert sérieux ?

Ce qui est ouvert

Modular affirme que Mojo est ouvert sous Apache 2.0 with LLVM exceptions. Le dépôt contient le compilateur, le tooling et le code nécessaire pour construire le langage. Le README place le compilateur dans /KGEN, la bibliothèque standard dans /mojo/stdlib, MAX accelerator library dans /max/kernels, ainsi que pipelines, exemples et docs. Il donne aussi un chemin de build via Bazel wrapper avec ./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo.

La différence avec les étapes précédentes est majeure. La bibliothèque standard et plusieurs composants étaient déjà ouverts, mais le cœur du langage restait propriétaire. Désormais le code, l’historique et les issues sont visibles. GitHub indique environ 27 000 étoiles, près de 3 000 forks et plus de mille issues ouvertes.

La licence compte aussi. Apache 2.0 avec exceptions LLVM est lisible pour de l’infrastructure compilateur. Elle ne répond pas à tout, mais elle facilite l’évaluation juridique et technique.

Ce qu’il ne faut pas confondre

La frontière avec MAX est essentielle. Modular dit que MAX n’a plus de device usage restrictions et parle de composants source-available, d’open alliance et de nouveaux accélérateurs. Mais MAX n’est pas l’ouverture du compilateur Mojo. Toute la Modular Platform n’est pas open source au même sens.

Une équipe doit donc séparer l’expérimentation du langage et la dépendance à la plateforme. Les licences, règles de distribution et contributions peuvent varier entre Mojo, MAX inference server, kernels et model pipelines.

La contribution est l’autre nuance. Le README accepte des contributions à la bibliothèque standard, MAX accelerator library, modèles, exemples et docs, mais pas encore au compilateur Mojo lui-même. Le code visible et le droit de fork ne suffisent pas à définir une gouvernance mature.

Pourquoi cela comptait

Un compilateur n’est pas une dépendance ordinaire. Il définit la sémantique, produit les artefacts et entre dans la base de confiance. Fermé, il demande de croire au fournisseur pour le support, les plateformes, la sécurité et la survie du projet. Pour un jeune langage face à Rust, Zig, Julia, C++, CUDA, Triton, Numba et Cython, c’était beaucoup demander.

Mojo visait justement des publics sensibles au tooling: infrastructure ML, développeurs Python orientés performance, auteurs de kernels, ingénieurs proches du matériel. L’ouverture du compilateur répond directement à leur objection principale.

Le débat communautaire

Hacker News et Lobsters montrent un intérêt net, mais pas naïf. Certains voient disparaître un critère éliminatoire. D’autres demandent si Mojo arrive trop tard, si Bazel complique la construction, ce que change Qualcomm, pourquoi les patchs du compilateur ne sont pas encore acceptés et si 1.0 est vraiment mature.

Ces questions sont bonnes. Puis-je construire depuis les sources ? Puis-je empaqueter l’outil ? Puis-je utiliser Mojo sans MAX ? Windows sera-t-il réel ? Que se passe-t-il si la stratégie commerciale change ? Un langage open source doit résister à ce genre d’examen.

Où Mojo peut servir

Mojo ne doit pas être réduit à “Python mais plus rapide”. Son intérêt est de combiner une syntaxe familière avec du contrôle de performance: ownership, lifetimes, programmation à la compilation, types explicites, SIMD, GPU et accélérateurs AI. Si cela tient, la niche existe.

Le premier public est celui qui écrit des kernels numériques, du traitement de données, de l’infrastructure d’inférence ou des parties critiques de bibliothèques, et qui utilise aujourd’hui C++, Rust, Cython, Numba, JAX, Triton ou CUDA. Mojo veut réduire le coût du changement de langage sans promettre de miracle.

Comment le tester

Le bon test est sobre. Installez l’outil, compilez un exemple, tentez un build depuis les sources, notez OS, matériel, temps de build, cache et erreurs. Comparez ensuite avec votre vraie alternative interne. Évaluez packaging, éditeur, tests, déploiement et onboarding, pas seulement la vitesse. Enfin, lisez licences, README et guide de contribution; séparez Mojo de MAX; traitez l’absence de contributions au compilateur comme une limite de gouvernance actuelle.

Verdict

Mojo mérite une nouvelle évaluation parce que la pièce cachée la plus importante est visible. Mais l’adoption dépendra des builds externes, de la documentation, du triage public, des limites de contribution, de Windows, des packages et d’une séparation honnête entre Mojo et MAX. Le compilateur ouvert n’est pas la conclusion; c’est le début de l’examen.