Maintenance et réversibilité : obtenir des livrables reprenables

Définir le contenu de la maintenance

Séparez la correction d’une anomalie, la mise à jour de composants et l’évolution fonctionnelle. Le contrat indique comment signaler un incident, qui le qualifie et quels engagements sont effectivement proposés. Ne confondez pas une prise en charge avec une résolution garantie. Les périodes de support, les exclusions et les dépendances couvertes doivent être explicites.

Demandez comment une mise à jour est testée puis mise en production. Les bibliothèques, le système et le moteur de données ont leurs propres cycles de maintenance. Une application qui fonctionne aujourd’hui peut nécessiter un travail de compatibilité lors d’un changement. La documentation doit identifier ces dépendances et leur propriétaire, sans inscrire de secrets dans les documents transmis.

Clarifier les droits et les accès

Faites distinguer les droits d’usage, les éventuels droits de modification et les conditions de remise du code. Le paiement d’un développement ne permet pas de supposer un transfert automatique de tous les droits. Les composants de tiers peuvent avoir des licences différentes. Une revue contractuelle adaptée peut être nécessaire pour préciser ce que l’entreprise et un futur repreneur pourront faire.

L’accès au dépôt, aux configurations et aux outils de déploiement doit correspondre au contrat. Le repreneur a besoin d’instructions pour construire l’application et de la liste des services externes. Il doit savoir créer un environnement de test sans demander des accès de production excessifs. Les clés et mots de passe sont transmis par un canal prévu, séparément de la documentation générale.

Démontrer une sortie opérationnelle

Faites livrer un export avec son dictionnaire de données, ses identifiants et ses pièces jointes. Vérifiez qu’il peut être lu et rapproché hors de l’application. Une archive binaire sans explication ne répond pas au même besoin qu’un jeu de données documenté. Définissez l’assistance au transfert, son chiffrage et les conditions de suppression des copies après la sortie.

Le Data Act traite notamment le changement de fournisseur de services de traitement de données dans son champ. Il ne doit pas être présenté comme une garantie universelle de transfert du code d’une application spécifique. Le contrat reste à examiner selon le service concerné. Préparez un exercice de reprise, avec un environnement et un résultat attendus, pour identifier les éléments manquants avant la fin de relation.

Exercice fictif pour préparer la recette

Demandez à un intervenant autorisé qui n’a pas construit l’application de créer un environnement de test avec la documentation livrée. Il doit identifier les composants, les services et les configurations nécessaires. Les erreurs rencontrées deviennent des compléments de documentation ou des dépendances à traiter. L’exercice se fait selon les droits contractuels, sans présumer que tous les composants peuvent être transmis librement.

Faites ensuite extraire un dossier fictif avec ses versions et ses documents. Vérifiez la lecture des formats et les relations entre objets. Une archive contenant toutes les lignes mais dépourvue de dictionnaire peut rester difficile à reprendre. Le propriétaire métier doit retrouver le sens des données hors de l’interface.

Préparez enfin une modification de règle et son retour possible. Le mainteneur montre les tests, la version livrée et les instructions d’exploitation. Le contrat doit préciser si ce travail relève de correction, de compatibilité ou d’évolution. Le DAF peut alors comparer les offres de maintenance avec leurs limites plutôt que sur un intitulé général de support.

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
• Prix d’une application métier web : comparer les devis
• Coût des ressaisies Excel : mesurer avant de décider
• Hébergement de l’application métier : vérifier l’exploitation
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel