Changer de prestataire de maintenance est une décision souvent prise sous contrainte : prestataire qui ne répond plus, délais trop longs, qualité insuffisante ou fin de collaboration. La reprise doit être organisée pour éviter une période de flottement où l'application n'est maintenue par personne.
Nticstudio a une procédure structurée pour la reprise de maintenance : audit préalable, passation avec l'ancien prestataire si possible, et démarrage progressif.
Phase d'audit avant la reprise
Avant de s'engager sur un SLA, Nticstudio réalise un audit technique de l'application à reprendre. Cet audit couvre : l'état du code (qualité, dette technique, absence de documentation), l'infrastructure (hébergeur, configuration, accès), les dépendances (versions, mises à jour en attente), et les incidents récurrents (bugs connus non corrigés).
L'audit prend 1 à 2 jours selon la complexité de l'application. Il produit un rapport qui liste les points de risque et définit les conditions de la reprise. Si l'état de l'application est trop dégradé, nous pouvons refuser la reprise ou proposer un chantier de stabilisation préalable.
Récupération des accès et de la documentation
La reprise nécessite la récupération de tous les accès : code source (dépôt Git), infrastructure (serveurs, base de données, services tiers), variables d'environnement, et documentation technique si elle existe.
Si l'ancien prestataire coopère, une session de passation technique accélère la prise de contexte. Si la relation est conflictuelle, la reprise se fait uniquement sur la base du code et de l'infrastructure accessibles. Dans ce cas, l'audit prend plus de temps.
Période de stabilisation
Si l'audit révèle une dette technique importante ou des incidents récurrents non résolus, une période de stabilisation est proposée avant de démarrer la maintenance contractuelle. Cette période (2 à 4 semaines) permet de corriger les problèmes bloquants, de documenter l'existant et de mettre en place le monitoring.
Démarre directement en maintenance sans cette phase de stabilisation expose au risque de s'engager sur un SLA difficile à tenir sur une base instable.
Démarrage du contrat Run
Une fois l'audit et la stabilisation éventuellement réalisés, le contrat Run démarre avec les engagements de SLA définis. Les premiers mois sont une période d'apprentissage : l'équipe monte en compétence sur les spécificités de l'application et affine les estimations de charge de maintenance.
Le reporting mensuel démarre dès le premier mois avec les métriques de disponibilité, les incidents traités et les recommandations proactives.