Plateforme SaaS
Vous vendez l'outil lui-même. Comptes, abonnements, rôles, facturation, multi-clients : l'architecture doit tenir la croissance dès le premier client.
Piège · négliger le multi-tenant au départPlateformes, SaaS et outils métier · IA-first
Ici, on ne parle pas de site vitrine. On parle des outils sur lesquels votre activité repose : une plateforme SaaS que vous vendez, un portail que vos clients utilisent chaque jour, un back-office qui remplace vos tableurs.
Depuis deux ans, l'IA écrit une large part de notre code sous contrôle senior. À budget égal, votre plateforme couvre plus de cas métier et arrive plus tôt.
Dans ces cas, un CMS ou un outil no-code fera mieux et moins cher. Nous vous le dirons — c'est plus rentable pour tout le monde qu'un projet mal orienté.
Des plateformes livrées et toujours en service.
C'est le seul critère qui compte.
Ce que nous développons
Chacune a ses pièges propres. Identifier la vôtre change le cadrage, l'architecture et la façon de mesurer le succès.
Vous vendez l'outil lui-même. Comptes, abonnements, rôles, facturation, multi-clients : l'architecture doit tenir la croissance dès le premier client.
Piège · négliger le multi-tenant au départVos clients suivent leurs commandes, déposent des documents, échangent avec vos équipes. Le vrai sujet est l'articulation avec vos systèmes existants.
Piège · sous-estimer les intégrationsIl remplace des tableurs, des e-mails et des habitudes. La réussite se joue sur l'adoption par vos équipes, pas sur la liste des fonctionnalités.
Piège · concevoir sans les utilisateursDeux populations, deux parcours, un modèle de transaction et une logique de confiance à installer. Un projet à part, plus proche d'une place de marché que d'un site.
Piège · lancer avec une seule offreParfois le produit n'a pas d'interface : c'est le socle qui alimente votre application mobile, vos partenaires et vos outils internes.
Piège · documenter après coupCe que change l'IA-first
Sur une plateforme métier, ce qui coûte cher n'est pas le cas standard : ce sont les vingt exceptions que vos équipes gèrent à la main depuis des années. Ce sont elles qu'on rogne d'abord, et c'est exactement pour elles que l'outil aurait été utile.
Le temps que nos développeurs passaient à écrire du code répétitif finance maintenant ces exceptions — et les tests qui les protègent.
Vos utilisateurs valident les écrans avant qu'on engage le budget de développement.
Les vingt cas particuliers que vos équipes traitent à la main entrent dans le périmètre.
Sur un outil métier, c'est ce qui permet de modifier sans casser deux ans plus tard.
Générée et relue à chaque livraison. C'est ce qui rend votre plateforme reprenable.
Ordres de grandeur observés sur nos projets 2025-2026, à périmètre comparable.
Comment on construit
Prises correctement, elles ne se remarquent pas. Prises à la légère, elles vous obligent à réécrire dans trois ans.
La décision la plus lourde et la plus difficile à corriger. Elle se prend avec votre métier, pas dans un coin par un développeur.
Qui voit quoi, qui peut modifier quoi. Ajouté après coup, cela contamine chaque écran et chaque requête.
ERP, CRM, comptabilité, outils métier : ce sont elles qui font déraper les plannings. On les cartographie et on les teste tôt.
Comptes internes, connexion via votre annuaire d'entreprise, accès partenaires. Cela conditionne l'expérience et la sécurité.
Chiffrement, journalisation des accès, durées de conservation, exports et suppression. Traité au départ, c'est peu coûteux.
Vos données existantes doivent entrer dans le nouvel outil, propres. C'est souvent 15 à 20 % du projet, et c'est presque toujours oublié dans les devis.
Où, chez qui, avec quelles garanties de disponibilité et de sauvegarde. Réversible si vous voulez changer, et documenté.
Reprise de projet
C'est une situation extrêmement fréquente : le développeur d'origine est parti, la documentation n'existe pas, chaque modification casse quelque chose ailleurs. Personne n'ose plus rien changer, et l'outil se dégrade doucement.
Notre audit répond à une question précise : que coûte la reprise, comparée à une réécriture ? Nous cartographions le modèle de données, les dépendances obsolètes, les failles ouvertes et les zones que personne ne comprend plus. Vous obtenez un plan chiffré en trois scénarios — stabiliser, reprendre, réécrire — et vous tranchez. Nous ne recommandons la réécriture que lorsqu'elle est réellement la moins chère des trois.
Après la mise en ligne
Vos usages évoluent, vos équipes demandent des ajustements, la réglementation change. Nous proposons un accompagnement continu avec un volume de jours défini, des priorités revues avec vous et une transparence complète sur ce qui est consommé.
Coûts et délais
Le chiffre exact vient après le cadrage. Une estimation donnée avant d'avoir compris le projet est une fiction confortable pour tout le monde sauf pour vous.
Fourchettes indicatives, août 2026. Obtenir une estimation cadrée →
Questions fréquentes
Un CMS ou un outil no-code excelle sur les besoins standards, et nous vous y renverrons si c'est votre cas. Le sur-mesure devient pertinent quand votre métier a des règles propres, quand vous devez vous connecter à des systèmes existants, quand le volume ou la sécurité comptent, ou quand l'outil est lui-même le produit que vous vendez.
React et Node.js sur la majorité des projets, Laravel quand le contexte s'y prête, PostgreSQL pour les données. Ce sont des choix mûrs, largement adoptés et donc faciles à reprendre par un autre prestataire ou par votre future équipe — ce critère compte autant que la performance.
Un prototype cliquable dans les deux à trois semaines, avant toute ligne de code, puis une démo fonctionnelle toutes les deux semaines. Sur un outil métier, faire tester ce prototype à vos utilisateurs réels est la meilleure dépense du projet.
Nous les auditons, les nettoyons et les reprenons dans le nouvel outil. C'est un chantier à part entière, souvent 15 à 20 % du projet, et nous l'annonçons dès le cadrage plutôt que de le découvrir en cours de route.
Oui, et c'est souvent la meilleure configuration. Nous pouvons prendre en charge la totalité, intervenir en renfort sur une partie, ou construire puis transférer avec une phase d'accompagnement. Nos standards de code et notre documentation sont conçus pour cela.
L'hébergement est à votre nom, chez un fournisseur que nous choisissons ensemble et qui répond à vos exigences de localisation — Union européenne par défaut. Vous disposez à tout moment d'un export complet de vos données dans un format standard, et l'infrastructure est décrite dans la documentation. Changer d'hébergeur ou de prestataire est un chantier planifiable, pas une négociation.
Votre plateforme
Trente minutes pour comprendre le métier, identifier ce qui doit exister dans la première version et repérer les vrais risques techniques.