Quand une entreprise parle de logiciel propriétaire sur mesure, elle ne désigne pas simplement un abonnement à un outil connu avec quelques réglages. Elle parle d’un logiciel métier conçu pour une entreprise ou une structure déterminée, selon ses processus, ses données et ses règles de travail. La notion de « propriétaire » doit toutefois être précisée : elle ne signifie pas automatiquement que tous les droits, le code source et les composants externes sont transférés sans condition.
Le bon cadrage consiste donc à décrire ce qui est construit, qui peut l’utiliser, qui peut le modifier, où se trouvent les données, qui assure la maintenance et comment l’entreprise peut reprendre la main. Les droits et obligations dépendent du projet et du contrat ; cet article propose une grille de préparation, pas une analyse juridique personnalisée.
Distinguer un outil métier sur mesure d’un produit standard
Un outil standard répond à un marché large. L’entreprise choisit une offre, active des options, configure des utilisateurs et utilise les fonctionnalités prévues par l’éditeur. Cette solution peut être pertinente lorsque les processus internes correspondent déjà au fonctionnement du produit.
Un logiciel sur mesure part du fonctionnement réel de l’entreprise : comment une demande arrive, qui la qualifie, quelles validations sont nécessaires, quels documents sont produits, quelles données doivent être rapprochées et quelles exceptions doivent être traitées. Le développement vise alors une organisation identifiée, plutôt qu’un ensemble indéterminé de clients.
La différence ne se résume pas à l’existence d’un logo ou à un écran personnalisé. Posez ces questions dès le départ :
- le logiciel répond-il à un processus propre à l’entreprise ?
- les règles métier et les écrans sont-ils définis pour ses équipes ?
- les données et les comptes sont-ils séparés de ceux d’autres clients ?
- l’entreprise peut-elle obtenir les éléments nécessaires à une reprise ?
- quelles briques restent génériques, sous licence ou fournies par un tiers ?
Cette distinction évite de présenter comme « propriétaire » un produit standard simplement reconfiguré. Elle aide aussi à choisir entre une solution existante, un développement spécifique ou une combinaison des deux. Pour relier cette décision à une démarche plus large, consultez la page offres et accompagnement digital.
Décrire précisément le besoin métier avant le développement
Un cahier des charges utile ne commence pas par une liste d’écrans. Il décrit le travail à réaliser et le résultat attendu à chaque étape. Pour un outil de gestion, documentez par exemple :
- les rôles des utilisateurs et leurs niveaux d’accès ;
- les informations créées, modifiées, importées ou supprimées ;
- les règles de validation et les cas qui nécessitent une intervention ;
- les notifications, documents ou exports à produire ;
- les outils avec lesquels le logiciel doit échanger ;
- les indicateurs nécessaires au pilotage, sans confondre activité et résultat commercial.
Prenez un exemple concret : une entreprise reçoit une demande, vérifie son périmètre, l’attribue à une personne, prépare un devis, suit les relances et clôture le dossier. Le logiciel peut formaliser ces étapes, signaler les informations manquantes et garder un historique. Il ne doit pas masquer les décisions qui restent humaines ni imposer des règles que l’équipe n’a pas validées.
Découpez ensuite le projet en versions. Une première version peut traiter le parcours central avec quelques rôles, une importation contrôlée et un export lisible. Les cas rares, les automatisations avancées et les tableaux de bord peuvent être ajoutés après une recette réelle. Cette approche rend les arbitrages visibles et limite le risque de construire une application difficile à utiliser.
Clarifier ce que l’entreprise possède et ce qu’elle peut faire
Le mot propriété recouvre plusieurs éléments qu’il faut séparer dans le contrat et les livrables : le code développé spécifiquement, la documentation, les maquettes, les scripts de déploiement, les bases de données, les contenus, les paramétrages et les composants réutilisables.
En droit français, les contrats par lesquels des droits d’auteur sont transmis doivent être constatés par écrit. L’article L131-3 du Code de la propriété intellectuelle prévoit aussi que les droits cédés et le domaine d’exploitation soient délimités ; consultez le texte officiel sur Légifrance et faites relire votre contrat par un professionnel compétent si l’enjeu le justifie.
Dans la pratique, demandez une réponse écrite à ces questions :
- l’entreprise reçoit-elle le code source ou seulement un accès à l’application ?
- peut-elle modifier le logiciel elle-même ou mandater un autre prestataire ?
- les droits couvrent-ils l’usage interne, la modification, la reproduction et la maintenance ?
- quelle est la portée des droits : durée, territoire et périmètre des éléments livrés ?
- quelles bibliothèques, API, polices, images ou briques open source ont leurs propres licences ?
- le prestataire conserve-t-il des composants génériques et, si oui, lesquels ?
Le statut des créateurs compte également. Pour les logiciels créés par des salariés dans l’exercice de leurs fonctions ou selon les instructions de leur employeur, l’article L113-9 du même code prévoit une règle spécifique de dévolution des droits patrimoniaux ; cela ne permet pas de déduire automatiquement la situation d’un développement confié à un prestataire externe. Il faut donc vérifier les conditions contractuelles applicables au projet.
Organiser le code, les données et les accès
La propriété pratique d’un outil ne se limite pas à une clause. Une entreprise doit pouvoir retrouver les éléments nécessaires à son exploitation : dépôt de code, historique des versions, configuration, documentation d’installation, variables d’environnement, procédures de sauvegarde et comptes d’administration.
Définissez qui contrôle au minimum :
- le dépôt de code et ses sauvegardes ;
- le nom de domaine, l’hébergement, la base de données et les services connectés ;
- les comptes d’administration et les moyens de récupération ;
- les clés d’API, certificats et secrets, stockés de façon appropriée ;
- les journaux utiles au diagnostic, avec une durée de conservation adaptée.
Évitez que tous les accès reposent sur une seule adresse personnelle du prestataire. Utilisez des comptes nominatifs, des rôles séparés et une procédure de retrait lorsqu’une personne quitte le projet. Si l’outil traite des données personnelles, la CNIL recommande de formaliser les responsabilités, la sécurité, les incidents, les audits et la restitution ou destruction des données dans l’encadrement de la sous-traitance. Consultez sa fiche sur la sécurité des traitements confiés à un sous-traitant.
Prévoir les intégrations et la réversibilité
Un logiciel métier vit rarement seul. Il peut échanger avec un CRM, un outil comptable, une messagerie, un agenda, un service de signature ou une plateforme de paiement. Chaque intégration ajoute une dépendance à documenter : compte propriétaire, données échangées, fréquence, format, limites, coût éventuel et comportement en cas d’indisponibilité.
La réversibilité consiste à prévoir la sortie avant d’en avoir besoin. Elle doit répondre à des questions très concrètes :
- dans quel format les données peuvent-elles être exportées ?
- les pièces jointes et l’historique sont-ils inclus ?
- qui fournit le schéma de données et la documentation ?
- combien de temps les accès restent-ils disponibles après la fin de la prestation ?
- comment les sauvegardes sont-elles remises, puis supprimées ou conservées ?
- qui accompagne une migration et selon quelles limites ?
Une exportation théorique ne suffit pas si elle ne peut pas être relue ou réimportée. Prévoyez un test d’export sur un environnement de recette, avec quelques cas représentatifs, avant la mise en production. La réversibilité peut aussi concerner les composants : si une API ou un service tiers disparaît, l’entreprise doit savoir quelles fonctions sont affectées et quelles alternatives sont envisageables.
Encadrer la maintenance et la sécurité dans le temps
Un développement terminé n’est pas un outil durable par lui-même. Le contrat et le dossier projet doivent distinguer correction d’anomalie, mise à jour de sécurité, évolution fonctionnelle, assistance, sauvegarde et surveillance. Indiquez les canaux de support, les horaires, les priorités, les délais de réponse attendus et les conditions d’intervention.
La sécurité doit accompagner le cycle de développement : séparation des environnements, revue du code selon le risque, gestion des dépendances, sauvegardes testées, contrôle des accès et procédure d’incident. L’ANSSI présente le cycle de développement sécurisé comme une démarche qui intègre la sécurité dans les étapes de conception, de développement et de déploiement ; voyez son étude sur le S-SDLC et le DevSecOps.
Pour un outil manipulant des données clients ou salariés, ajoutez une recette de confidentialité et de droits d’accès : un utilisateur ne doit voir que les dossiers utiles à son rôle, les exports doivent être contrôlés et les comptes inactifs désactivés. Si une fonctionnalité repose sur un traitement de données personnelles, faites vérifier le cadre applicable et les responsabilités avant l’ouverture à toute l’équipe.
Recetter le logiciel avec les utilisateurs
La recette doit vérifier le travail réel, pas seulement l’absence d’erreur à l’écran. Préparez des scénarios représentant les parcours courants et les exceptions : création d’un dossier, modification après validation, accès d’un rôle limité, import incomplet, doublon, export, interruption d’un service tiers et restauration d’une sauvegarde.
Pour chaque scénario, notez la donnée de départ, l’action attendue, le résultat observé, la personne qui valide et le traitement d’une anomalie. Faites tester l’outil par les utilisateurs qui l’emploieront réellement, sur un environnement séparé des données de production. La documentation doit être mise à jour au fur et à mesure des décisions, pas rédigée uniquement à la fin.
Un projet peut aussi combiner un logiciel métier sur mesure et un agent IA en entreprise. Dans ce cas, définissez séparément les données auxquelles l’agent accède, les actions qu’il peut proposer ou exécuter, les validations humaines et les journaux à conserver. Ne laissez pas une automatisation élargir les droits du logiciel sans décision explicite.
La prochaine étape
Avant de demander un devis, rédigez une fiche d’une page : processus ciblé, utilisateurs, données, intégrations, première version, critères de recette, accès attendus et scénario de sortie. Demandez ensuite que le devis, les livrables et les conditions contractuelles distinguent clairement le spécifique, le générique, les composants tiers, les droits d’utilisation, la maintenance et la réversibilité.
Si le périmètre reste flou, commencez par un atelier de cadrage plutôt que par un développement complet. Pour présenter votre besoin et vérifier les prochaines étapes, vous pouvez utiliser la page contact de l’Agence Digi. Une solution propriétaire utile est une solution que l’entreprise comprend, peut exploiter et peut faire évoluer avec des responsabilités clairement définies.