Logiciel métier : le développer en interne ou le confier

Un logiciel métier se développe en interne quand l’entreprise réunit durablement les compétences d’architecture, de sécurité et de tests, et le temps de piloter le projet. À défaut, le confier à une équipe extérieure structurée protège sa continuité. Le choix se joue sur cinq terrains : compétences, départs, délai de première version, propriété du code, maintenance.

Logiciel métier : les compétences présentes et celles qui manquent

Un logiciel métier outille un processus propre à l’activité : planification des interventions, chiffrage technique, suivi de fabrication. Quand le marché répond mal à une façon de travailler, l’entreprise envisage une application métier conçue pour elle. Reste à savoir qui la construira.

L’inventaire se fait sans complaisance. Beaucoup de PME comptent un informaticien polyvalent, un développeur web recruté pour le site ou un utilisateur avancé du tableur. Ces profils apportent la connaissance du métier, l’atout le plus difficile à acheter. Trois domaines leur échappent pourtant souvent :

• l’architecture : découpage de l’application, modèle de données, hébergement, échanges avec les autres outils par API (interfaces de programmation) ;
• la sécurité : authentification, droits par profil, protection des données personnelles au sens du RGPD (règlement général sur la protection des données) ;
• les tests : tests automatisés, puis recette, c’est-à-dire la vérification formelle par les utilisateurs avant la mise en production.

La CNIL donne la mesure du sujet : son Guide RGPD du développeur, dans la version publiée le 13 décembre 2021, consacre des fiches séparées à la gestion du code source, à l’architecture, à la qualité du code et aux tests, autant de savoir-faire à part entière.

S’y ajoute la conception des écrans, dont dépend l’adoption par les équipes, comme le rappelle l’histoire du flat design et de ses limites d’utilisabilité. Confier tout ce périmètre à une seule personne crée un point de fragilité, quel que soit son talent.

La continuité quand le développeur s’en va

Le scénario est banal : le développeur qui a écrit l’outil démissionne. Son préavis laisse rarement le temps d’un vrai passage de relais, et son successeur découvre un code sans documentation, un hébergement ouvert au nom d’un salarié parti, des choix que personne ne sait justifier.

Le risque tient moins au talent qu’à la concentration du savoir. Tant qu’une seule personne connaît la logique des calculs ou le mot de passe du serveur, chaque correction dépend d’elle. Un indépendant (freelance) expose au même danger, sa disponibilité variant avec ses autres clients.

Trois protections limitent ce risque : une documentation à jour, écrite pour un lecteur absent du projet ; des tests automatisés qui signalent toute régression ; des conventions de code partagées. Ce dernier point rejoint notre article sur les frameworks CSS et leur courbe d’apprentissage : une convention se transmet mal dans une équipe qui tourne.

Faute de pouvoir garantir ces protections en interne, la continuité du logiciel repose alors sur une agence développement logiciel, où le savoir se partage entre plusieurs personnes au lieu de tenir à une seule. Digital Unicorn met en regard les deux autres voies, le recrutement interne et l’indépendant, en signalant les difficultés qu’elles peuvent poser : un recrutement complexe, plusieurs intervenants à coordonner, une cohérence et un suivi à tenir dans la durée. Sa méthode part de l’analyse des besoins, passe par une conception UX/UI (expérience et interfaces) pensée pour les futurs utilisateurs, un développement qui intègre la sécurité, des tests et un contrôle qualité, jusqu’à la mise en service. Pour une PME, cette chaîne répond directement au risque de départ : besoins, maquettes et tests deviennent des éléments écrits que d’autres peuvent reprendre.

Reste le calendrier, côté entreprise. Le délai d’une première version dépend moins de la vitesse d’écriture du code que du temps que la PME consacre à expliquer ses règles, à arbitrer et à valider ce qu’elle reçoit.

Première version : délai réel et charge de pilotage

Une première version utile, souvent appelée produit minimum viable (MVP), couvre le cœur du processus et lui seul : la saisie et l’affectation d’une intervention, par exemple, avant la facturation et les statistiques.

En interne, le compteur démarre avant la première ligne de code : définition du poste, recherche, entretiens, préavis du candidat retenu, prise en main. Une équipe déjà en place démarre plus vite, si ses autres missions lui laissent du temps. Un développeur partagé entre le site et le nouvel outil avance par à-coups.

Confié à une équipe extérieure, le projet s’ouvre sur un cadrage : ateliers avec les utilisateurs, règles de gestion, maquettes des écrans. Le développement part ensuite d’une base validée, avec des livraisons intermédiaires testées au fil de l’eau.

Dans les deux cas, le pilotage reste à la charge de la PME, et se sous-estime presque toujours. Il repose sur un référent métier disponible, qui tranche sans remonter chaque question à la direction et se charge de :

• relire les règles de gestion et leurs exceptions ;
• arbitrer les priorités aux points d’avancement ;
• préparer des données réalistes et conduire la recette ;
• organiser la formation et la bascule depuis l’ancien outil.

Si l’outil sert sur tablette en intervention, la recette se fait sur les terminaux réels, selon la démarche de notre dossier sur l’adaptation mobile d’un site web.

En interne s’ajoute une charge moins visible : encadrer un profil technique que la direction ne sait pas toujours évaluer. Avec un prestataire, le suivi porte sur des jalons et des livrables, plus lisibles pour un dirigeant non technicien.

Code, dépôts et accès : une propriété à verrouiller dans tous les cas

Pour un salarié, l’article L113-9 du Code de la propriété intellectuelle attribue à l’employeur, seul habilité à les exercer, les droits patrimoniaux sur les logiciels et leur documentation créés dans l’exercice des fonctions ou d’après ses instructions, sauf dispositions statutaires ou stipulations contraires.

Le texte vise les employés. Un prestataire, société ou indépendant, n’entre pas dans ce cadre : la propriété du code qu’il écrit se règle par le contrat, qui organise la cession des droits. Sans clause claire, un doute subsiste sur ce que l’entreprise peut faire du logiciel : le modifier, le confier à une autre équipe, l’étendre à une filiale.

L’INPI rappelle que le droit d’auteur protège les logiciels et applications informatiques dès leur création, sans formalité. Dater cette création reste utile en cas de litige, et l’institut cite notamment son service e-Soleau, un dépôt électronique qui horodate l’œuvre.

Quelle que soit l’organisation, l’entreprise garde aussi la main sur :

• le dépôt de code, sous un compte d’organisation qu’elle administre ;
• le nom de domaine, l’hébergement et les services tiers, à son nom ;
• les mots de passe et clés d’accès, dans un coffre-fort numérique partagé ;
• la documentation technique et le schéma de la base de données ;
• la liste des bibliothèques à code source ouvert et de leurs licences.

Un développeur interne qui héberge le code sur son compte personnel crée la même dépendance qu’un prestataire qui conserve seul les accès.

Maintenir le logiciel métier sur plusieurs années

La livraison ouvre la période la plus longue, et la maintenance du logiciel y recouvre quatre chantiers :

• la correction des anomalies découvertes à l’usage ;
• les évolutions demandées quand l’activité change ;
• la mise à jour technique du langage, des bibliothèques et du système ;
• l’application des correctifs de sécurité dès leur publication.

Négliger le troisième chantier accumule de la dette technique, c’est-à-dire l’écart entre l’état du code et ce qu’exigerait son évolution sereine. Chaque version sautée rend la suivante plus coûteuse, jusqu’au jour où une modification simple réclame une refonte.

En interne, tout se joue sur la redondance. Un logiciel maintenu des années par une seule personne reproduit le risque de départ, en plus grave, car le code a grossi. Deux personnes capables d’intervenir constituent un minimum raisonnable.

Confiée à un prestataire, la maintenance se formalise dans un contrat : périmètre, délais d’intervention, conditions de sortie. Cette dernière clause organise la réversibilité, soit la capacité de transférer le logiciel vers une autre équipe avec son code, sa documentation et ses accès. Elle oblige chacun à tenir le dossier à jour.

Cette documentation s’écrit pour être lue : les principes d’une écriture claire et structurée pour le web valent aussi pour un guide d’exploitation.

Grille de décision : interne, confié ou mixte

Chaque critère oriente vers une organisation, aucun ne tranche seul.

• Compétences : architecture, sécurité et tests présents en interne plaident pour développer sur place ; un généraliste isolé oriente vers une équipe extérieure ou un modèle mixte.
• Continuité : deux personnes au moins, en interne ou chez le prestataire, savent reprendre le code.
• Délai : une première version attendue vite favorise une équipe déjà constituée.
• Pilotage : un référent métier reste requis ; une direction peu technique suit plus sereinement des jalons contractuels.
• Propriété : dépôts, comptes et droits restent à l’entreprise.
• Durée de vie : un outil appelé à durer exige une maintenance garantie, interne et étoffée, ou contractuelle et réversible.
• Stratégie : un logiciel qui porte l’avantage concurrentiel justifie, à terme, une compétence interne.

Le modèle mixte combine les forces des deux voies : un responsable produit interne porte la connaissance du métier, une équipe extérieure conçoit et développe, puis un transfert progressif s’organise si l’entreprise décide d’internaliser. Ce transfert se prévoit dès le contrat.

Prochaine étape : réunir le dirigeant, le futur référent et la personne la plus technique de l’entreprise, remplir la grille, puis lister les accès existants avec le nom de leur titulaire. Cette liste mesure déjà la dépendance de l’outil actuel, avant le lancement du nouveau logiciel métier.

Les questions qui reviennent avant de trancher

Qu’est-ce qui distingue un logiciel métier d’un ERP ?

Un ERP, ou progiciel de gestion intégré, couvre les fonctions communes à la plupart des entreprises : comptabilité, achats, stocks, ventes. Ses règles standard se paramètrent. Un logiciel métier outille un processus propre à une activité, comme la planification d’interventions techniques ou le suivi d’un dossier réglementaire. Les deux coexistent souvent : le logiciel métier échange alors ses données avec l’ERP par des interfaces de programmation, ce qui évite les doubles saisies entre services.

Le code écrit par un prestataire appartient-il à l’entreprise ?

Pas automatiquement. La règle du Code de la propriété intellectuelle qui attribue à l’employeur les droits sur les logiciels créés par ses salariés ne vise pas un prestataire extérieur. La cession des droits se négocie donc dans le contrat, qui précise ce que l’entreprise pourra faire du logiciel : l’utiliser, le modifier, le faire évoluer par un tiers. Le même contrat prévoit la remise du code source, de la documentation et des accès.

Une équipe interne peut-elle reprendre un logiciel confié à l’extérieur ?

Oui, si la reprise se prépare dès le départ : clause de réversibilité, documentation livrée à chaque version, dépôt de code au nom de l’entreprise. La reprise passe ensuite par une période de recouvrement. Les futurs développeurs internes participent aux dernières évolutions avec l’équipe d’origine et corrigent leurs premières anomalies sous supervision. Privée de cette phase, l’équipe qui hérite du code découvre seule des choix techniques qu’elle n’a pas faits.