Votre projet en ligne

La reprise de données décide du calendrier

Une application qui remplace un outil existant hérite de son contenu : clients, commandes, factures, historique. Cette reprise de données est rarement une simple copie. Les formats diffèrent, des champs obligatoires d'un côté sont vides de l'autre, des doublons coexistent depuis des années, et des codes maison ne veulent rien dire hors de leur contexte. Le travail consiste à cartographier l'ancienne base de données, à décider ce qui se reprend et ce qui s'archive, puis à rejouer la bascule plusieurs fois sur des copies avant la vraie. C'est le poste qui fait déraper les calendriers quand il est estimé à la louche, et celui qui rassure quand il est traité en premier.

Les intégrations dépendent de ce que les autres acceptent

Une application vit rarement seule : elle échange avec une comptabilité, un transporteur, une caisse, un outil de paiement. Chaque intégration API dépend de ce que l'éditeur d'en face autorise, documente et maintient. Une interface bien documentée se branche en quelques jours. Une interface absente oblige à passer par des échanges de fichiers, avec leurs horaires, leurs erreurs silencieuses et leur rattrapage manuel. La question se pose donc avant le chiffrage, et elle s'adresse à vos éditeurs : proposent-ils une interface, à quelles conditions, et avec quelles limites de volume. La réponse change le budget plus sûrement que le nombre d'écrans.

Les droits se décident avant d'écrire le premier écran

Dès que plusieurs personnes utilisent une application, la question de qui voit quoi se pose, et elle se pose mal après coup. Un commercial doit-il consulter les marges ? Un intérimaire peut-il annuler une commande ? Une facture validée reste-t-elle modifiable, et par qui ? Ces réponses ne sont pas techniques, elles décrivent votre organisation, et elles structurent le code en profondeur. Rajouter une notion de rôle sur une application qui n'en avait pas coûte plusieurs fois le prix de l'avoir prévue. Nous posons donc la question au cadrage, même quand une seule personne doit utiliser l'outil au départ.

Un tableau de bord qui sert est un tableau de bord qu'on regarde

La demande revient naturellement : un tableau de bord qui montre tout. Le résultat est souvent un écran dense que personne n'ouvre après le premier mois. Un écran utile répond à une question précise, posée par quelqu'un de précis, à un moment précis de la semaine. Trois chiffres qui déclenchent une décision valent mieux que vingt courbes qui décrivent une situation. Nous partons donc des décisions à prendre, puis nous remontons aux données nécessaires, plutôt que l'inverse. Ce qui reste hors écran n'est pas perdu : il s'exporte quand le besoin se présente.

La recette se prépare, elle ne se découvre pas à la livraison

Avant la mise en service, l'application tourne sur un environnement de recette, une copie complète où vos données de test vivent sans conséquence. C'est là que les écarts se voient : un calcul juste sur trois commandes et faux sur la quatrième, un export qui perd les accents, un droit d'accès trop large. Cette phase se prévoit au calendrier et vous y participez, parce que personne ne connaît vos cas particuliers mieux que vous. Une recette expédiée en une après-midi reporte simplement les corrections après la mise en service, au moment où elles coûtent le plus cher.

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde

La sauvegarde automatique est devenue une case cochée par défaut, et c'est précisément le problème : personne ne vérifie qu'elle fonctionne avant d'en avoir besoin. Une sauvegarde se définit par trois choses, sa fréquence, sa durée de conservation, et le temps qu'il faut pour remettre le service debout à partir d'elle. La troisième est la seule qui compte le jour venu, et la seule qui se teste. Elle se vérifie en la restaurant une fois sur un environnement de recette, procédure écrite à l'appui, et ce test se demande à l'hébergeur. Cela vaut pour la base de données comme pour les fichiers déposés par vos utilisateurs.

Hébergement infogéré ou autonome, le choix se fait tôt

Une application demande un environnement entretenu : mises à jour de sécurité du système, certificats renouvelés, surveillance des ressources, journalisation. Un hébergement infogéré délègue cet entretien à un prestataire, pour un coût mensuel plus élevé et une tranquillité réelle. C'est ce que désigne la tierce maintenance applicative : confier l'entretien d'une application à un prestataire extérieur, en distinguant toujours le correctif de l'évolutif pour que le budget de l'un ne mange pas celui de l'autre. Un hébergement autonome coûte moins cher et suppose que quelqu'un s'en occupe, ce qui est tenable dans une structure qui a une personne pour ça, et illusoire ailleurs. Le choix se décide avant le développement, parce qu'il influence l'architecture : une application pensée pour un environnement maîtrisé ne se déplace pas sans frais vers un autre.

La prise en main se prépare, elle ne s'improvise pas le jour J

Un outil métier ne se découvre pas comme un site : il remplace une habitude, souvent un tableur que chacun manipulait à sa façon. La bascule réussit quand les personnes concernées ont vu l'écran avant la mise en service et ont pu dire ce qui manquait. Elle échoue quand elle arrive par un courriel un lundi matin. Nous prévoyons donc une session sur vos propres données, pas sur un jeu de démonstration, et une courte documentation écrite dans votre vocabulaire plutôt que dans celui du logiciel. Le temps passé là évite les semaines de contournement qui suivent une mise en service mal préparée.