OccupySaaS veut refaire Auth0 et Salesforce avec l’IA

OccupySaaS, collectif lancé en octobre 2026, dit vouloir reconstruire avec l’IA des alternatives open source à des logiciels vendus par abonnement, en commençant par Auth0 et Salesforce. Le groupe reprend une critique classique du SaaS: la dépendance aux éditeurs, la facturation par utilisateur et la sortie compliquée d’un service à l’autre. Pour l’instant, il propose surtout une démonstration technique, pas un remplaçant prêt à brancher en production.

Refaire du SaaS sans payer la facture, ou presque

Le slogan du mouvement est direct: « Ils nous ont licenciés. Nous reconstruisons leurs SaaS. ». OccupySaaS revendique une approche open source, auto-hébergeable et sans frais de licence, avec l’idée de casser la dépendance à des plateformes qui verrouillent souvent les entreprises par leurs API, leurs intégrations et leurs mécanismes de migration. Le nom fait écho à Occupy Wall Street, né à New York en 2011, mais la cible ici reste bien plus technique que financière.

Le collectif ne précise pas les anciens employeurs de ses initiateurs ni les raisons de leur départ. Aucun élément public ne permet donc de confirmer qu’ils ont travaillé chez les éditeurs visés, ni que leur départ relève de licenciements liés à l’IA. C’est un point non négligeable, car la dimension militante du projet repose aussi sur ce récit.

Une méthode de « clean room » sous supervision humaine

OccupySaaS dit s’appuyer sur des agents d’IA capables de générer du code à partir de spécifications techniques rédigées par des développeurs. Le code produit passe ensuite par une revue humaine. L’approche revendiquée est celle de la clean room, ou réimplémentation en salle blanche: reproduire le fonctionnement d’un logiciel à partir de documentation publique, de standards ouverts et du comportement observable de ses API, sans utiliser de code propriétaire ni d’informations confidentielles. En clair, on regarde comment la machine tourne, mais on ne pique pas les plans sous le capot.

Cette méthode vise un objectif concret: permettre à des équipes réduites d’aller plus vite tout en conservant une compatibilité suffisante avec les usages existants. Les tests de compatibilité s’appuient sur les kits de développement publics des éditeurs, afin que certaines applications et intégrations continuent de fonctionner après un changement de solution. La promesse est séduisante, mais elle ne vaut pas migration automatique.

Deux chantiers visibles: ZeroAuthy et SalesCompel

Le premier projet, ZeroAuthy, a été rendu public le 14 octobre 2026. Développé en Go, il cherche à reproduire les fonctions d’Auth0, la plateforme de gestion des identités et des accès d’Okta. Sa première version candidate, publiée le 4 novembre, prend en charge plusieurs mécanismes d’authentification, la gestion des utilisateurs et certaines API d’administration. Le logiciel a aussi obtenu une certification OpenID pour trois profils OpenID Connect, sans que cela constitue une validation globale de sa sécurité.

Le second projet, SalesCompel, a été publié le 15 octobre 2026 pour concurrencer Salesforce sur le marché du CRM. Il repose sur Go et PostgreSQL, avec un éditeur d’enregistrements développé en Vue.js. Son socle actuel gère des comptes, des contacts, certaines requêtes et une partie des API de Salesforce. En revanche, il ne reprend pas le code Apex, les automatisations Flow ni les interfaces personnalisées de Salesforce, qui restent hors périmètre de cette première version.

La compatibilité, oui. La migration complète, non.

Les deux logiciels sont distribués sous licence Apache 2.0, qui autorise leur utilisation, leur modification et leur exploitation commerciale. Sur le papier, cela ouvre la porte à des déploiements internes ou à des contributions externes. Dans les faits, leur couverture fonctionnelle reste incomplète, et le collectif précise lui-même que ses outils ne sont pas prêts pour une utilisation généralisée en production.

La question de fond touche à la réversibilité des systèmes d’information. Si une alternative reprend les mêmes API qu’un logiciel propriétaire, certaines applications peuvent continuer à tourner sans refonte majeure. Mais dans un environnement Salesforce, les personnalisations, automatisations et extensions tierces restent à reprendre. La compatibilité technique ne suffit donc pas à effacer la complexité d’une sortie.

Le Data Act change le décor, mais pas la mécanique

L’initiative arrive alors que l’Union européenne pousse davantage la portabilité des données. Applicable depuis le 12 septembre 2025, le Data Act vise à faciliter le changement de fournisseur de services de traitement des données, notamment dans le cloud. À partir du 12 janvier 2027, les frais de changement de fournisseur visés par le règlement, y compris les frais de sortie des données, devront être supprimés.

OccupySaaS s’inscrit donc dans un contexte réglementaire plus favorable aux migrations, mais son modèle ne règle pas tout. L’auto-hébergement suppose de gérer la maintenance, les mises à jour, la supervision, les sauvegardes et les correctifs de sécurité, des tâches particulièrement sensibles pour un service d’authentification. L’absence de frais de licence ne signifie pas absence de coût. Le cloud adore les petites lignes; les factures, un peu moins.

Un collectif encore fragile

OccupySaaS cherche désormais de nouveaux contributeurs et évoque de futures cibles comme la documentation collaborative, le suivi des incidents ou le support client. Pour le moment, rien n’indique que ce chantier a atteint une taille suffisante pour affronter des plateformes établies dans des environnements d’entreprise complexes.

Au 8 novembre 2026, l’organisation GitHub du collectif n’affiche aucun membre public, ce qui empêche d’évaluer sa base réelle. Ses deux projets donnent une idée de la méthode, pas encore de la robustesse. Le mouvement a posé une idée simple: si un logiciel propriétaire verrouille trop fort, il faut parfois le reconstruire de zéro. Reste à voir combien de temps une communauté peut tenir ce rythme sans se transformer en chantier permanent.