Développer une application web pour sa PME : 7 erreurs qui coûtent cher après le lancement

Pourquoi le premier outil interne est le plus risqué

Une PME qui fait développer sa première application web découvre des décisions qu'elle n'a jamais eu à prendre : propriété du code, hébergement, sauvegardes, contrats sur les données. Personne en interne n'a le réflexe de poser ces questions, et beaucoup de devis ne les abordent pas. Les erreurs ci-dessous ne relèvent pas de la technique : ce sont des erreurs de cadrage, faciles à éviter au moment de signer, très coûteuses à corriger ensuite.

Les erreurs d'organisation (tout vouloir changer en même temps, négliger l'accompagnement des équipes) sont traitées dans notre article sur les erreurs classiques de la transformation digitale. Celles-ci concernent le projet lui-même.

1. Ne pas être propriétaire du code

En France, payer un développement ne suffit pas à en devenir propriétaire. Pour un logiciel créé par vos salariés dans le cadre de leurs fonctions, les droits reviennent à l'employeur (article L113-9 du Code de la propriété intellectuelle). Mais pour un prestataire externe, ils restent au créateur tant qu'ils n'ont pas été cédés par écrit, et l'article L131-3 du même code exige que chaque droit cédé fasse l'objet d'une mention distincte, avec son étendue, sa destination, son lieu et sa durée. Vérifiez que le contrat prévoit cette cession, et que le code source vous est effectivement remis, pas seulement l'accès à l'application.

2. Laisser tous les comptes au nom du prestataire

Nom de domaine, hébergement, dépôt du code, comptes des services tiers (envoi d'emails, paiement, cartographie) : si tout est ouvert au nom du prestataire, vous dépendez entièrement de lui, y compris pour partir. Ouvrez ces comptes au nom de votre entreprise et donnez-lui des accès ; l'inverse est beaucoup plus difficile à défaire.

3. Oublier le contrat de sous-traitance des données

Dès que l'application contient des données personnelles (clients, salariés, candidats), le prestataire qui l'héberge ou la maintient agit comme sous-traitant au sens du RGPD. Son article 28 impose alors un contrat qui précise ce qu'il peut faire de ces données, les mesures de sécurité appliquées et ce que deviennent les données en fin de contrat. Demandez aussi où elles sont hébergées, et quels autres services y ont accès.

4. Sous-estimer la reprise des données existantes

Vos clients, vos historiques et vos tarifs vivent aujourd'hui dans des tableurs, un ancien logiciel ou des emails. Les transférer n'est jamais un simple copier-coller : doublons, formats de dates différents, colonnes remplies à la main depuis des années. Prévoyez la reprise dès le devis, sur la base d'un échantillon réel de vos fichiers, et désignez en interne une personne chargée de valider les données importées.

5. Valider sans faire tester par ceux qui l'utiliseront

La recette, cette phase où l'on vérifie que tout fonctionne avant la mise en ligne, est souvent faite par le dirigeant, en quelques minutes, sur son ordinateur. Or ce sont les utilisateurs quotidiens qui trouvent les vrais problèmes : le champ obligatoire qu'on ne peut jamais remplir au moment de la saisie, l'écran illisible sur la tablette de l'atelier, le bouton trop petit pour des mains gantées. Faites tester chaque rôle, sur les vrais appareils, avec des cas réels.

6. Ne prévoir aucun budget après la livraison

Une application web n'est jamais vraiment terminée. Les composants sur lesquels elle repose publient des correctifs de sécurité, les navigateurs évoluent, vos besoins changent. Prévoir un budget de maintenance, même modeste, et un contrat qui précise les délais d'intervention évite de découvrir un jour qu'une faille connue n'a jamais été corrigée, ou qu'une petite évolution nécessite de tout reprendre.

7. Ne jamais tester la restauration des sauvegardes

La bonne question n'est pas « est-ce sauvegardé ? » mais « avons-nous déjà restauré ? ». Une sauvegarde incomplète, chiffrée avec une clé perdue ou stockée sur le même serveur que l'application ne sert à rien le jour de l'incident. Demandez un test de restauration avant la mise en ligne, puis au moins une fois par an.

Le point commun : la réversibilité

Toutes ces erreurs ont la même conséquence : elles rendent le départ impossible. Or la meilleure garantie de qualité, c'est de pouvoir changer de prestataire sans perdre votre outil. Avant de signer, posez une seule question : « Si nous arrêtons de travailler ensemble, que récupérons-nous, et comment ? »

La réponse doit tenir en une liste précise :

• le code source, avec la cession des droits correspondante ;
• les accès au domaine, à l'hébergement et aux services tiers, à votre nom ;
• les données, dans un format standard et exploitable ;
• la documentation nécessaire pour qu'une autre équipe puisse reprendre.

C'est aussi le meilleur moyen de vérifier que vous achetez une vraie application web, et pas un site déguisé.