Aller au contenu principal

Application web et plateforme métier sur mesure à Lyon

Une application web métier, ce n'est pas un site avec un espace de connexion. C'est un outil où plusieurs types d'utilisateurs font des choses différentes sur les mêmes données, avec des règles qui changent selon qui regarde.

C'est cette complexité-là qui fait la différence entre un projet qui tient trois ans et un projet qu'on réécrit au bout de dix-huit mois.

Ce qu'on entend par plateforme métier

Quatre familles, qui reviennent presque toujours :

  • Portail client — vos clients suivent leurs commandes, leurs documents, leurs demandes, sans appeler votre équipe.
  • Extranet partenaires ou revendeurs — chacun voit son périmètre, ses tarifs, son stock.
  • Outil interne multi-équipes — plusieurs métiers travaillent sur le même dossier avec des droits différents.
  • Produit SaaS — vous vendez l'outil à vos propres clients, avec des comptes séparés et une facturation.

Les quatre questions qui déterminent tout

Posées au cadrage, elles décident de l'architecture, et une erreur sur l'une d'elles coûte une réécriture :

  1. Qui voit quoi ? Les rôles et les permissions ne s'ajoutent pas après coup, ils structurent le modèle de données.
  2. Avec quoi ça se connecte ? ERP, comptabilité, outil de paie, transporteur, CRM. Chaque intégration a ses contraintes et son rythme de synchronisation.
  3. Combien d'utilisateurs simultanés, et sur quel volume ? Une plateforme à 20 utilisateurs et une à 2 000 ne se construisent pas pareil.
  4. Qu'est-ce qui doit être tracé ? Qui a modifié quoi, quand, et pourquoi. Dans beaucoup de métiers, c'est une obligation, pas un confort.

Quand une plateforme sur mesure ne se justifie pas

  • Quand un outil du marché couvre 80 % du besoin et que les 20 % restants ne valent pas une refonte.
  • Quand le vrai problème est l'adoption d'un outil existant, pas son absence.
  • Quand le processus change encore tous les mois : on fige du mouvant.

Un cas : une plateforme à trois portails pour Klass

KLASS SARL, à Dijon, monte une offre de sous-traitance pédagogique pour les écoles supérieures et les CFA. Toute la chaîne devait tenir dans un seul outil : contrats, séances, émargement et facturation.

Nous avons construit trois portails, un espace école, un espace opérations et un espace intervenant, pour douze rôles, avec un cloisonnement strict entre établissements. Le cycle de mission y est complet : dépôt de besoin, rapprochement pondéré avec les intervenants, bon de commande signé par lien, incidents et remplacement, évaluations à chaud et à froid, émargement par QR code, attestations, double facturation et export comptable.

Un programme de vérification maison rejoue 269 contrôles à chaque mise à jour : accès, cloisonnement, scénarios métier, liens, données structurées, accessibilité. Zéro erreur, ou la mise à jour ne part pas.

Lire la fiche complète du projet Klass

Questions fréquentes

Quelle différence entre un site web et une application web métier ?

Un site présente de l'information. Une application web fait travailler des gens : saisie, validation, droits différents selon les profils, données qui circulent avec vos autres outils. La complexité ne se voit pas à l'écran, elle est dans les règles métier et dans ce qui se passe quand deux personnes modifient la même chose.

Peut-on connecter la plateforme à notre ERP ou notre comptabilité ?

Oui, c'est même le cas le plus fréquent. Ce qui change d'un projet à l'autre, c'est ce que l'outil existant autorise : une API documentée, un export de fichiers, ou rien du tout. Cette vérification se fait au cadrage, parce qu'elle détermine une grande partie de la charge de travail.

Combien de temps avant d'avoir quelque chose d'utilisable ?

Nous livrons par étapes validées, et la première met en service un périmètre restreint mais réel plutôt qu'une maquette. Le découpage dépend du projet et se définit au cadrage. Vous voyez fonctionner les premières parties avant que l'ensemble soit terminé.

Peut-on reprendre une plateforme développée par quelqu'un d'autre ?

Oui. Le travail commence toujours par un audit : état du code, dépendances obsolètes, documentation existante, risques de migration. Cet audit conditionne la suite, parce que reprendre coûte parfois plus cher que reconstruire — et il vaut mieux le savoir avant.

Et si on veut vendre l'outil à nos propres clients plus tard ?

Cela se décide au départ. Un outil interne et un produit SaaS ne partagent pas la même architecture : séparation des comptes, facturation, niveaux d'abonnement, supervision. Transformer l'un en l'autre après coup est possible mais coûteux. Autant poser la question au cadrage, même si la réponse est « peut-être ».

Cadre de travail

Le code spécifique développé pour votre projet vous est remis selon les conditions prévues au contrat, avec les dépôts, la documentation et les accès. Les composants tiers restent soumis à leurs licences.

Cinq étapes, un livrable validé à chacune. Le chiffrage vient après le cadrage. Notre méthode

Bureau à Lyon et à Dijon. Nous intervenons aussi en dehors de la région.

Pour aller plus loin