Maintenance du connecteur ERP : cadrer le support

Décrire le service après la mise en production

La maintenance commence par l’inventaire des composants : ERP, extensions, connecteur, middleware et plateforme. Pour chacun, identifiez le fournisseur et le contrat applicable. Un incident peut traverser plusieurs composants ; le dossier doit préciser qui suit le ticket jusqu’au rapprochement final. La présence d’un support ne prouve pas que toutes les interfaces sont couvertes.

Séparez correction d’un défaut, assistance à l’utilisateur, évolution technique et nouvelle demande métier. Les conditions financières et les responsabilités peuvent différer. Les délais d’intervention ou de résolution doivent être ceux convenus dans le contrat. Demandez des engagements qui décrivent leur périmètre, les horaires et les exclusions, avec une procédure d’escalade utilisable par votre équipe.

Organiser les alertes autour des documents

Une alerte doit dire quel flux est affecté et quels documents sont concernés. Un message « erreur interface » sans contexte ne permet pas à la comptabilité de décider une action. Demandez une vue des factures en attente, en erreur et sans réponse, avec références de corrélation. La supervision technique peut compléter cette vue, mais ne doit pas la remplacer.

Attribuez chaque type d’anomalie à un propriétaire. La DSI traite une indisponibilité d’accès ; le propriétaire métier traite une donnée de tiers ou une décision comptable. Le suivi doit conserver l’incertitude lorsqu’une réponse n’est pas parvenue. Évitez une reprise automatique qui émet un nouveau document sans rapprochement préalable. Les alertes ne doivent pas diffuser inutilement le contenu des factures à des destinataires collectifs.

Contrôler les accès de support

Identifiez les comptes techniques, les droits utilisateurs et les moyens d’intervention du prestataire. Les accès doivent être adaptés à la fonction et pouvoir être retirés. La procédure doit prévoir leur renouvellement et le contrôle des changements. Une personne chargée du diagnostic n’a pas nécessairement à disposer du droit de modifier une facture ou de relancer un flux.

Demandez comment les interventions sont tracées et comment l’entreprise peut retrouver les actions réalisées. Les journaux peuvent contenir des données sensibles pour l’activité ; leur consultation et leur export doivent être encadrés. Prévoyez le départ d’un intervenant et le transfert du support à une autre équipe. Le dossier doit rester exploitable sans partager des identifiants personnels ni dépendre d’un compte inconnu de l’entreprise.

Tester les changements d’interface

Les APIs, formats et profils peuvent évoluer. La documentation DGFiP distingue les spécifications et les normes applicables ; les références doivent être suivies dans votre configuration. Un changement annoncé ne doit pas être appliqué sans analyse de son effet sur le mapping et les workflows. Demandez qui réalise cette analyse et qui valide le résultat métier.

Conservez un environnement de test et des jeux fictifs représentatifs. Les tests doivent comparer documents, réponses et états dans l’ERP. Un changement qui passe la validation technique peut modifier une donnée utilisée par les achats ou la comptabilité. Les jeux de régression doivent donc couvrir les références et les cas particuliers. Le contrat doit préciser les travaux inclus dans le suivi des évolutions et ceux qui seront chiffrés séparément.

Préparer une procédure d’incident

Décrivez les premières vérifications : disponibilité des composants, existence du document et réponse reçue. Le support doit pouvoir identifier le point où le parcours s’est interrompu. La procédure conserve les preuves avant modification. Une capture d’écran peut aider, mais les références de message et les journaux sont souvent nécessaires au diagnostic technique.

La reprise doit être autorisée selon la situation. Une facture déjà reçue ne doit pas être émise à nouveau pour faire disparaître une alerte locale. Après intervention, rapprochez les documents et vérifiez l’état final. Le comptable doit savoir quelles pièces restent en attente. Un incident clos techniquement peut laisser une anomalie métier ; le suivi doit distinguer ces deux niveaux de clôture.

Vérifier la réversibilité du support

Demandez la remise de configuration, dictionnaire, procédures et jeux de recette. Les licences peuvent rester celles du fournisseur, mais l’entreprise doit comprendre son propre parcours de données. Faites préciser l’export des journaux et le maintien de l’accès aux documents. Une sortie du contrat ne doit pas être découverte au moment où le support devient indisponible.

Organisez une revue du dossier après les changements significatifs. Les contacts, les flux et les accès peuvent avoir évolué depuis la mise en service. La revue vérifie que les responsabilités décrites correspondent encore à la situation réelle. Demandez un scénario de reprise suivi par l’équipe interne pour constater qu’elle peut utiliser la documentation remise, sans assistance permanente du concepteur initial.

Grille à joindre à la consultation

Livrable attendu

Le livrable de maintenance comprend une matrice d’escalade, un registre des composants et une procédure d’incident. Faites remettre un exemple de diagnostic sur une interruption puis sa reprise autorisée. La DAF valide le rapprochement des documents et la DSI valide les accès et la supervision. Les interventions restant à la charge de l’entreprise doivent être décrites. Conservez les réserves et les exclusions avec le contrat afin que les équipes sachent ce qu’elles peuvent demander au support.