Audit de l’application existante : connaître les dépendances

Observer l’usage puis examiner la technique

Commencez par suivre un dossier du début à la fin avec les utilisateurs. Notez les ressaisies, les contrôles informels, les fichiers satellites et les opérations que seule une personne sait effectuer. Une difficulté décrite comme un problème informatique peut provenir d’une règle de gestion contradictoire ou d’une responsabilité mal définie. La direction doit pouvoir distinguer ces situations avant de financer un remplacement.

L’examen technique inventorie les fichiers, les bases, les interfaces, les versions, le code disponible et les composants externes. Pour Access, les formulaires et les macros comptent autant que les tables. Pour Excel, les liaisons et les feuilles masquées peuvent porter des dépendances. Pour SQL Server, les traitements planifiés et les comptes de service doivent être recensés. Faites préciser ce qui a été inspecté et ce qui reste inconnu.

Qualifier le risque sans verdict automatique

Classez les constats par conséquence : interruption, perte d’intégrité, accès excessif ou difficulté de maintenance. Une technologie ancienne ne prouve pas seule que le système est inutilisable. À l’inverse, une interface récente peut masquer l’absence de restauration testée. L’audit doit expliquer le scénario de risque, les preuves disponibles et les mesures possibles, avec leurs conditions de faisabilité.

Identifiez les droits d’usage et les livrables dont l’entreprise dispose. Le fait de posséder un fichier exécutable ne signifie pas que le code source peut être modifié librement. La qualification contractuelle se vérifie dans les documents, avec conseil adapté si nécessaire. Distinguez les inconnues de droit, les inconnues techniques et les décisions métier. Une liste unique de problèmes ne permet pas d’affecter les responsabilités.

Recevoir des options réellement comparables

Demandez au moins la présentation des options pertinentes : corriger l’existant, mettre à niveau une version, isoler un processus ou reconstruire l’application. Chaque option décrit les usages couverts, les données à reprendre, les dépendances conservées et les contraintes d’exploitation. Le prestataire peut écarter un scénario, mais doit expliquer pourquoi. Une recommandation sans alternative ne permet pas d’évaluer le compromis.

Le livrable indique les prochaines investigations, les pièces nécessaires au chiffrage et les critères de décision. Faites livrer les constats sous une forme consultable par l’équipe, avec les limites de l’examen. L’audit ne vaut pas automatiquement recette ni certification de sécurité. La direction choisit la trajectoire après lecture des conséquences opérationnelles et du coût total, en réservant du temps interne pour valider les règles qui n’ont jamais été documentées.

Exercice fictif pour préparer la recette

Choisissez un dossier fictif représentatif et demandez à l’utilisateur de dérouler toutes les étapes qu’il ferait sur l’existant. Il décrit les fichiers qu’il ouvre, les contrôles qu’il réalise et les informations qu’il récupère ailleurs. Notez les opérations manuelles et les connaissances tacites. Le rapport d’audit doit permettre de distinguer les fonctions de l’outil des habitudes qui l’entourent.

Faites relier ce parcours à l’inventaire technique. Une extraction employée pour un reporting doit avoir une source et un responsable. Si une macro est appelée mais que son rôle n’est pas connu, elle reste une inconnue explicitement à examiner. Le candidat doit décrire les limites de son observation, notamment lorsqu’une opération rare n’a pas été vue.

Demandez enfin ce que chaque trajectoire change pour ce même dossier. La conservation peut nécessiter une correction ; la reconstruction peut supprimer une ressaisie et en introduire une autre. L’exercice compare les conséquences sans préjuger du choix. Le livrable final conserve les preuves, les dépendances et les investigations restantes pour qu’un autre intervenant puisse comprendre la recommandation.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• Cahier des charges métier : exprimer usages et critères de recette
• Power Apps ou application sur mesure : comparer les contraintes
• ERP ou application métier : placer les règles au bon endroit
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel