Développement logiciel sur mesure pour les entreprises en France et en Belgique

Traduire vos règles métier en logiciel

Avant de compter les écrans, nous évaluons votre projet de logiciel sur mesure à partir des décisions qui structurent votre activité. Qui accepte une commande ? Dans quelles conditions est-elle refusée ? Que se passe-t-il lorsque le stock est insuffisant ? Comment une correction ultérieure est-elle enregistrée ? Ces questions constituent le point de départ de la conception. Si des collaborateurs accomplissent la même tâche de différentes manières, il faut définir une règle commune avant de l’automatiser. Sinon, le logiciel ne résout pas l’ambiguïté : il la propage plus vite.

Pendant la phase de découverte, nous travaillons sur des documents types, des enregistrements anonymisés et les exceptions rencontrées au quotidien. Les opérations annulées, les informations manquantes, les prix erronés et les demandes non autorisées font partie du périmètre du projet, au même titre que le parcours normal. Pour chaque module, nous décrivons le résultat attendu, le rôle utilisateur et le comportement prévu en cas d’échec. Le projet passe ainsi d’une liste générale de fonctionnalités à des scénarios de recette mesurables.

Si un produit standard répond à votre besoin, développer un nouveau système n’est pas nécessaire. Le développement sur mesure prend tout son sens lorsque vos règles de décision sont spécifiques, que les périmètres de données diffèrent entre organisations ou que vos opérations ne sont pas couvertes par les produits existants. Lors du premier échange, nous déterminons ensemble ce qu’il faut conserver, ce qu’il faut modifier et pourquoi ces changements sont nécessaires.

Application web : droits d’accès, intégrité des opérations et déploiement

Une application de gestion accessible depuis un navigateur ne se limite pas à des écrans adaptés au mobile. Masquer un bouton à l’écran ne constitue pas une mesure de sécurité suffisante : à chaque requête, le serveur doit vérifier le droit de l’utilisateur à lire ou à modifier l’enregistrement concerné. Nous traduisons les limites liées aux agences, aux services et aux comptes clients dans les requêtes de données. Les accès indirects, tels que les listes, les exports et les téléchargements de fichiers, sont soumis aux mêmes règles.

Lorsque plusieurs personnes travaillent sur le même enregistrement, nous prévoyons la gestion des conflits de modification. Plutôt que de laisser un formulaire obsolète écraser des informations plus récentes, le système donne à l’utilisateur la possibilité de les réexaminer. Une opération qui touche plusieurs tables est conçue pour ne pas laisser de données incohérentes si elle s’interrompt. Les effets externes, comme l’envoi d’une notification, peuvent être exécutés après la finalisation de l’opération principale.

Le plan de mise en production prend en compte simultanément la version de l’application, les modifications de la base de données et la procédure de retour arrière. L’existence d’une sauvegarde dont la restauration n’a jamais été testée ne suffit pas à démontrer que le système peut être rétabli. La recette comprend un essai de restauration, des contrôles des droits d’accès et l’examen des requêtes les plus utilisées avec le volume de données cible. La saisie de codes-barres par le personnel d’entrepôt et la consultation d’un rapport détaillé par un responsable n’appellent pas la même interface.

Conception CRM : identification des clients et historique commercial

Dans un projet CRM, la première question n’est pas de créer une fiche client, mais de relier correctement les enregistrements d’un même client provenant de différents canaux. Un numéro de téléphone ne constitue pas toujours un identifiant fiable à lui seul : une ligne d’entreprise partagée ou un changement de coordonnées peut entraîner une fusion erronée. Nous définissons qui peut fusionner ou dissocier les fiches et comment leur historique doit être préservé.

L’opportunité commerciale et la fiche client ont des cycles de vie distincts. Plusieurs opportunités peuvent être suivies pour un même client ; la perte d’une opportunité ne justifie pas la suppression de ce client. Les révisions de devis, le prix approuvé et les changements de commercial responsable restent traçables. Les étapes du pipeline commercial ne sont pas de simples colonnes colorées : elles s’appuient sur des conditions de passage et des informations obligatoires.

La date de référence des rapports est particulièrement importante : les résultats peuvent varier selon qu’ils reposent sur la date de création, de clôture ou d’encaissement. Nous ne produisons pas d’indicateurs avant que l’équipe se soit accordée sur leurs définitions. Pour relier un formulaire web, un journal d’appels ou un service de messagerie au parcours CRM, vous pouvez vous appuyer sur nos solutions d’intégration. Dans ces interconnexions, nous sélectionnons les champs utiles à l’objectif poursuivi plutôt que de copier des données personnelles superflues.

ERP et gestion commerciale : concevoir les écritures de mouvement

Dans un logiciel de gestion des stocks et des comptes clients et fournisseurs, un simple champ modifiable indiquant le solde actuel ne suffit pas à expliquer l’origine des opérations. Les entrées, sorties, écarts d’inventaire, retours et transferts sont modélisés par des enregistrements distincts. Lorsqu’une pièce est annulée, son historique peut être conservé et relié à un mouvement correctif plutôt que supprimé. Cette approche permet à l’équipe comptable de retracer l’origine d’un montant.

L’unité de la fiche produit, les conversions de conditionnement, les variantes et le code d’entrepôt sont précisés dès le départ. Pour un produit acheté par carton mais vendu à l’unité, les conversions, les arrondis et les règles relatives au stock négatif sont vérifiés à l’aide de cas de test. Le temps pendant lequel une marchandise circule entre deux entrepôts constitue également un état du processus : il serait incorrect de la présenter comme disponible dans les deux entrepôts à la fois.

Le module de gestion commerciale ne remplace pas les obligations ni les responsabilités liées à la comptabilité officielle. Nous définissons avec les collaborateurs concernés où les données comptables et opérationnelles se rejoignent, ainsi que le logiciel qui fait référence. Lors de la première migration, les soldes d’ouverture et les totaux des mouvements sont rapprochés ; l’ancienne source n’est pas abandonnée avant validation des écarts. Pour les liens entre étapes de production, consommation de matières et produits finis, vous pouvez également consulter notre approche du secteur industriel et de la production.

Produit SaaS : isolation des organisations et états d’abonnement

Pour un SaaS, nous définissons le périmètre des données de chaque organisation avant de concevoir l’écran d’abonnement. La sélection de l’organisation ne repose pas sur un simple paramètre envoyé par l’utilisateur : l’appartenance et les droits d’accès sont vérifiés côté serveur. Les fichiers, les rapports, les tâches planifiées et les résultats de recherche doivent respecter la même règle d’isolation. Les scénarios de recette utilisent deux comptes d’organisations distinctes pour rechercher d’éventuels accès croisés.

Le changement d’offre, l’échec d’un paiement, la fin d’un essai et la résiliation d’un abonnement font partie du fonctionnement quotidien du produit. Des décisions produit écrites précisent si ces événements modifient les accès immédiatement ou à la fin de la période. Le devenir des données d’un compte ayant atteint sa limite d’utilisation, son droit à l’export et les modalités de réactivation ne restent pas indéterminés. Nous ne promettons pas de modèle d’encaissement sans avoir vérifié les possibilités du prestataire de paiement.

La première mise en production doit comprendre un parcours d’utilisation complet, utile à lui seul. La délimitation des développements ultérieurs ne doit pas conduire à reporter la sécurité ou l’intégrité des données. Lorsque l’usage nécessite un accès mobile, le développement d’une application mobile est planifié comme un besoin distinct du cœur du produit, tout comme la conception du site web destiné à le présenter.

Portail B2B : visibilité des prix et validation des commandes

Le prix affiché dans un portail distributeurs peut reposer sur des règles différentes de celles du catalogue public. Le groupe de distributeurs, le contrat, la catégorie de produits, la devise et la quantité commandée peuvent influer sur le tarif. Nous déterminons la priorité de ces règles à partir de commandes types. Il faut préciser à quel moment le montant affiché dans le portail est figé dans la commande et si un changement de prix impose une nouvelle validation du client.

L’affichage du solde du compte client et l’autorisation de commander avec un paiement à échéance sont deux sujets distincts. Une commande peut rester à l’état de brouillon en raison d’un plafond de crédit, d’un encaissement en attente ou d’une validation du commercial. Les annulations, les expéditions partielles et les changements de produits doivent permettre d’expliquer l’écart entre le montant initial et le montant final de la commande. L’adresse et les informations commerciales en vigueur à la date de l’opération sont conservées indépendamment des modifications ultérieures de la fiche client.

Dans l’interconnexion avec l’ERP, la réception d’une commande et son acceptation par l’ERP correspondent à deux états différents. Le message présenté au distributeur est conçu en conséquence. Les dispositifs qui incluent aussi la vente aux consommateurs peuvent être étudiés avec une solution e-commerce ; les droits des distributeurs et les tarifs réservés ne sont toutefois pas confondus avec le parcours de la boutique publique.

Réservations : capacité, durée et prévention des conflits

Un système de réservation ne se contente pas d’afficher des cases colorées sur un calendrier. Un même créneau peut nécessiter la disponibilité simultanée de plusieurs ressources : salle, personnel, appareil ou véhicule. Les temps de préparation et de nettoyage influent eux aussi sur la capacité. Lorsque plusieurs utilisateurs sélectionnent simultanément un créneau libre, la décision finale doit être prise côté serveur en préservant l’intégrité de la transaction ; le fait que deux navigateurs affichent chacun ce créneau comme libre ne donne pas, à lui seul, un droit de réservation.

Le lien entre la durée du blocage temporaire et le résultat du paiement est défini séparément. Nous précisons la procédure à appliquer si une confirmation de paiement réussi arrive après l’expiration du blocage. Les fuseaux horaires, les prestations qui dépassent minuit, les jours fériés et les congés du personnel sont intégrés aux données de test. Le droit d’annulation et le remboursement reposent sur les décisions de l’entreprise ; le logiciel les applique au moyen d’états compréhensibles.

Un parcours de réservation ajouté à un site existant et une interface opérationnelle indépendante répondent à des usages différents. Les exemples de sites de location de véhicules et de sites de cliniques et de médecins illustrent pourquoi une même logique de calendrier nécessite des périmètres de ressources et d’informations différents.

Comment comparer un progiciel et un développement sur mesure ?

La comparaison ne porte pas seulement sur le prix d’achat, mais aussi sur la pérennité de l’exploitation. Pour un progiciel, nous examinons la politique de mise à jour, l’export des données, les droits d’accès et les interconnexions autorisées. Pour un développement sur mesure, nous tenons compte des ressources consacrées à l’analyse, à l’exploitation, aux mises à jour de sécurité et à l’évolution des besoins. Aucune des deux approches n’est, par nature, sans maintenance ni coût.

Conserver le logiciel comptable existant et développer séparément les circuits de validation et de planification propres à l’entreprise est une option souvent étudiée. Nous évaluons ensemble l’ampleur de la migration, l’effort d’apprentissage pour les équipes et le risque de gérer les mêmes données à deux endroits. Plutôt que de fonder le choix uniquement sur le nombre d’utilisateurs ou sur le nom d’une technologie, nous le justifions à partir de cas métier concrets.

Choisir votre partenaire sur la base de la recette et de la passation

Pour comparer les devis, la manière dont la livraison sera validée compte autant qu’une démonstration fonctionnelle. Avant de considérer un module comme terminé, il faut déterminer qui testera quels scénarios, les niveaux de gravité des anomalies et la façon de traiter les points encore ouverts. Les attentes du chef de projet peuvent différer de celles des utilisateurs quotidiens ; nous intégrons donc au groupe de recette les personnes qui réalisent les opérations.

Nos projets de logiciels sur mesure sont encadrés par un contrat et font l’objet d’une facturation. La remise du code source, de la structure de la base de données et des informations d’installation fait partie de la passation ; les conditions de l’assistance technique pendant un an après la livraison y sont également définies. Les licences des composants tiers sont détaillées séparément. Une demande de nouvelle fonctionnalité est distinguée d’une anomalie dans un comportement validé ; les responsabilités à maintenir après la période de maintenance font l’objet d’un échange spécifique.

La documentation de passation ne doit pas se limiter à une liste de fichiers. Elle décrit les paramètres d’environnement, les tâches, les responsables des accès et les procédures de reprise ; les secrets sont conservés séparément des documents consultables. Vous pouvez examiner les fonctionnalités visibles de nos réalisations en production sur notre page de références. Le périmètre technique varie d’un projet à l’autre : les fonctionnalités d’une référence ne sont donc pas automatiquement incluses dans un nouveau projet.