BlogMéthode · 28 septembre 2026

Partir d'un socle entretenu plutôt que de zéro

Sur mesure ne veut pas dire tout réinventer. Ce qu'apporte un socle commun, entretenu et vérifié, et comment il cohabite avec ce qui est propre à chaque projet.

Tous les articles Nous écrire

Partir d'un socle entretenu plutôt que de zéro

Chaque application métier est différente, et pourtant toutes ont besoin des mêmes fondations : des comptes et des rôles, une gestion des droits, des formulaires, des envois d'e-mails, des journaux d'activité, des sauvegardes. Réécrire ces briques à chaque projet coûte du temps et multiplie les occasions d'erreur. À l'inverse, tout faire entrer dans un outil générique finit par contraindre ce qui fait la singularité du client. Entre les deux, il existe une voie : partir d'un socle commun, entretenu, et construire par-dessus ce qui est propre au projet. C'est le principe du Hultra Framework.

Le problème du « zéro »

Une rangée de fondations en béton identiques, coulées séparément et vides. — Repartir de zéro, c'est couler chaque fois les mêmes fondations.

Repartir d'une page blanche donne une impression de liberté. En pratique, une grande partie du travail consiste à refaire ce qui a déjà été fait ailleurs : l'inscription, la réinitialisation du mot de passe, l'invitation d'un collaborateur, l'export d'un tableau. Ces fonctions ne différencient pas un projet. Elles doivent simplement fonctionner, de façon sûre.

Chaque réécriture ajoute aussi du code à maintenir. Cinq projets partis de zéro, ce sont cinq façons de gérer les droits, cinq façons d'envoyer un e-mail, et cinq endroits où corriger une faille le jour où elle est découverte.

Trois couches distinctes

Le Hultra Framework s'organise en trois couches, chacune avec un rôle clair.

Le socle

C'est la base commune à tous les projets : la structure de l'application, l'authentification, la gestion des rôles, les conventions de code, l'outillage de test et de déploiement. Le socle est entretenu en continu par le studio. Il n'est pas figé : il évolue au fil des projets et des évolutions techniques.

Les modules réutilisables

Ce sont des fonctions que l'on retrouve dans de nombreux projets, sans qu'elles soient universelles : un module de facturation, un module de prise de rendez-vous, un module de gestion documentaire. On les active quand le projet en a besoin, et on les paramètre selon le contexte.

Les modules spécifiques

C'est ici que se trouve le cœur du projet : les règles métier propres au client, ses parcours, ses calculs, ses écrans. Ces modules sont écrits pour lui. C'est là que se concentre l'essentiel de l'effort de conception, parce que c'est là que se crée la valeur.

Ce que le client y gagne

Du temps sur l'essentiel. Les briques communes étant déjà là, le projet consacre son budget à ce qui est propre à l'activité.

Des fondations déjà éprouvées. Le socle a servi sur d'autres projets. Ses défauts ont eu l'occasion d'être découverts et corrigés.

Des améliorations partagées. Quand le socle progresse, les projets peuvent en profiter.

Une reprise facilitée. Un développeur qui connaît le socle comprend plus vite n'importe quel projet construit dessus.

La question de la compatibilité

Un socle partagé pose une question légitime : que se passe-t-il quand il évolue ? Une amélioration utile à un projet ne doit pas en casser un autre.

C'est pourquoi les évolutions communes ne sont jamais appliquées à l'aveugle. Chaque mise à jour du socle est intégrée avec une vérification de compatibilité : on regarde ce qui change, on exécute les tests du projet, et l'on adapte ce qui doit l'être. Cette discipline s'appuie sur des pratiques bien connues dans l'industrie logicielle, comme le versionnage sémantique, qui distingue les changements compatibles de ceux qui demandent une adaptation.

La norme ISO/IEC 14764, consacrée à la maintenance du logiciel, distingue d'ailleurs plusieurs natures de maintenance : corrective, adaptative, perfective et préventive. Un socle entretenu permet de mutualiser une bonne partie de la maintenance adaptative et préventive, celle qui consiste à suivre l'évolution des technologies et à anticiper les problèmes.

Ce que le socle n'est pas

Pour éviter les malentendus, quelques précisions.

Ce n'est pas un logiciel prêt à l'emploi. Le Hultra Framework sert à construire des applications sur mesure, pas à en livrer une identique à chaque client.

Ce n'est pas une contrainte sur le métier. Les modules spécifiques sont libres de modéliser l'activité telle qu'elle est.

Ce n'est pas une boîte noire. Le code propre au projet appartient au client selon les termes du contrat, et les composants tiers restent sous leurs licences respectives. Nous y revenons dans un article consacré à la propriété du code.

Comment cela se passe dans un projet

Au cadrage, nous identifions ce qui relève du socle, ce qu'un module existant couvre déjà, et ce qui doit être écrit spécifiquement. Ce découpage rend le projet plus lisible : chacun sait où se situe l'effort, et pourquoi. La page le framework Hultra présente cette organisation plus en détail.

Questions fréquentes

Mon application dépendra-t-elle du studio pour toujours ?

Non. Le code est documenté et construit selon des conventions standards. Une autre équipe peut le reprendre. Le studio reste disponible pour l'accompagnement, sans que ce soit une obligation technique.