Une plateforme, trois cibles : web, iOS et Android sur le même socle.

Beaucoup de projets démarrent par une question piégée : « on fait le web d'abord, ou le mobile ? ». La question elle-même révèle une hypothèse coûteuse — celle qu'il faut construire des applications séparées pour chaque support. C'est le modèle classique, et c'est précisément celui qu'on évite.

Chez nous, une plateforme se construit une fois, sur un socle commun, puis se décline en web, iOS et Android. C'est ce qu'on appelle le 3-en-1. Voici ce que ça veut dire techniquement, et ce que ça change pour vous.

Le coût caché de trois applications séparées

Construire trois applications natives indépendantes, c'est trois bases de code, trois équipes ou trois compétences, trois cycles de tests, trois déploiements. Et surtout, c'est trois fois la maintenance : chaque évolution métier doit être réimplémentée trois fois, avec le risque que les versions divergent.

Pour la plupart des plateformes métier — pas pour un jeu vidéo ou une app à effets graphiques poussés — cette séparation n'apporte presque rien à l'utilisateur, mais multiplie le coût et les délais. C'est une dépense qu'on paie par habitude, pas par nécessité.

Un socle, des déclinaisons

L'approche par socle commun part de l'inverse : la logique métier, les données, les droits, les règles — tout ce qui fait la valeur de la plateforme — sont écrits une seule fois. Le web et le mobile en sont des déclinaisons, qui partagent ce cœur et adaptent uniquement l'interface au support.

Concrètement, quand vous faites évoluer une règle de gestion, elle change partout en même temps. Quand vous ajoutez une fonctionnalité, elle arrive sur les trois cibles sans triple travail. Le mobile n'est pas un projet à part : c'est la même plateforme, sous une autre forme.

Ce que ça change pour vous

Les limites, honnêtement

Cette approche couvre l'immense majorité des plateformes métier : gestion, suivi, saisie terrain, tableaux de bord, parcours. Elle a ses limites pour les usages qui exigent le meilleur du natif — jeu, traitement d'image lourd, fonctions matérielles très pointues. Dans ces cas, on assume du natif spécifique là où c'est justifié, et on garde le socle commun pour tout le reste.

Pour une plateforme métier, le 3-en-1 n'est pas un compromis : c'est le bon défaut. Web, iOS et Android, même socle, même équipe — et un seul endroit à faire évoluer.