Il arrive parfois qu’en construisant sa roadmap, un DSI se demande si son prestataire tient encore la route. Le doute peut venir d’un incident mal géré, de délais qui s’allongent ou d’une documentation devenue introuvable. Il peut aussi venir d’un sentiment plus diffus, celui de ne plus être en pilotage, et vient alors la question de changer de prestataire IT.
Ce n’est pas une décision anodine. Elle engage la continuité de service, la qualité du SI et souvent plusieurs années de collaboration. Prise à chaud elle coûte cher, mais prise trop tard elle laisse la dette technique s’accumuler jusqu’au point de rupture. Cet article vous donne les 6 signaux d’alerte à surveiller, la méthode pour décider sans céder à l’émotion, et le parcours structuré qui permet de basculer proprement quand la décision est prise.
Les 6 signaux d’alerte qui doivent vous faire douter de votre prestataire
Un signal isolé n’est pas nécessairement une raison de rompre. Cependant, leur cumul, leur récurrence et surtout leur nature doivent alerter. Voici les 6 signaux qui reviennent le plus souvent dans les missions de reprise que nous menons.
1. Les délais de réponse et de résolution s’allongent
C’est le signal le plus visible et le plus mesurable. Un ticket ouvert le lundi, encore sans réponse le vendredi, un incident P2 traité comme un P4, ou encore des mises en production qui glissent sans explication claire doivent alerter. Si vos SLA contractuels ne sont plus tenus et que les explications deviennent floues, ce n’est donc plus un accident mais un symptôme.
2. La documentation devient introuvable ou obsolète
Vous demandez la doc d’un module, on vous répond que « c’est dans la tête d’un tel ». Les schémas d’architecture datent d’il y a trois ans et ne reflètent plus la réalité du code. Aucune mise à jour n’a été intégrée aux specs depuis les dernières évolutions. Ce signal est structurel, car un prestataire sain documente en continu. Ainsi, une documentation défaillante trahit une dette invisible qui explosera au premier départ.
3. Une seule personne connaît vraiment votre projet
C’est le fameux facteur bus. Un développeur senior peut porter à lui seul l’histoire du projet, les choix techniques et les subtilités métier. S’il part, tombe malade ou change d’affectation, la connaissance disparaît alors avec lui. Un prestataire mature répartit donc la compétence sur au moins deux à trois profils par mission. Une dépendance à un seul homme est un risque opérationnel majeur pour l’entreprise.
4. Le prestataire refuse ou évite les audits externes
Vous proposez de faire auditer le code par un tiers indépendant, la réponse est évasive et on vous parle de coût, de délai ou de confidentialité. Un prestataire confiant dans la qualité de sa livraison accueille l’audit externe comme une preuve de professionnalisme. Un prestataire défaillant le vit comme une menace, et cette différence est révélatrice.
5. Les incidents récurrents ne sont jamais adressés à la racine
Le même bug revient tous les trois mois sous des formes différentes. Les correctifs sont posés en surface, sans post-mortem, sans analyse de cause racine. Personne ne prend le temps de comprendre pourquoi ça casse, on se contente de réparer et on passe à autre chose. C’est un signal de dette technique qui s’accumule silencieusement, jusqu’au jour où un incident majeur révèle l’empilement.
6. L’opacité règne sur la roadmap technique
Les évolutions arrivent sans concertation. Les choix techniques structurants sont pris sans validation ni pédagogie. Vous découvrez a posteriori qu’un composant critique a été mis à jour, refactorisé ou remplacé. Un prestataire de confiance doit impliquer le DSI dans les décisions structurantes, alors qu’un prestataire défaillant avance seul, quitte à créer des surprises désagréables.
Rester ou partir : comment trancher sans décider à chaud
Un ou deux signaux ne justifient pas nécessairement de tout arrêter. Certaines situations sont réversibles avec un cadrage contractuel plus strict, une clarification des SLA ou un changement d’interlocuteur côté prestataire. D’autres sont cependant structurelles et imposent la bascule. La grille suivante aidera à séparer les deux.
| Type de signal | Réversible avec cadrage | Impose une bascule |
|---|---|---|
| Délais et SLA | Renégociation contractuelle, escalade formalisée | Défaillance chronique malgré rappels |
| Documentation | Rattrapage programmé sur 3-6 mois | Refus explicite ou incapacité à produire |
| Facteur bus | Onboarding d’un second profil imposé | Perte du seul sachant, opacité maintenue |
| Refus d’audit | Non concerné (signal binaire) | Refus caractérisé = bascule |
| Incidents non résolus | Mise en place d’une revue post-mortem | Dette technique déjà critique |
| Opacité roadmap | Comité technique mensuel formalisé | Absence de transparence maintenue |
Une décision de changement se prend en croisant la gravité des signaux et la volonté du prestataire de se remettre en question. Si les signaux sont majeurs et que le prestataire ne bouge pas, la bascule devient une question de gestion des risques, pas de préférence personnelle.
Reste donc à évaluer le coût du statu quo face au coût du changement. Le statu quo n’est jamais gratuit, entre dette technique qui s’aggrave, coûts de maintenance qui augmentent et incidents qui pèsent sur l’exploitation. Le changement a un coût visible (audit, transfert, remise à niveau) mais il est borné dans le temps.
L’audit applicatif : le premier pas avant toute décision lourde
Selon les analyses relayées par Gartner, la dette technique peut consommer jusqu’à 40% de la valeur d’un patrimoine applicatif d’entreprise. Un audit applicatif indépendant est l’étape la plus efficace pour transformer un ressenti en diagnostic chiffré.
Concrètement, un audit d’application métier couvre quatre volets. Le premier est technique et concerne la qualité du code, le respect des standards, la présence de tests automatisés et le niveau de dette technique. Le deuxième est architectural avec la cohérence de la stack, la dépendances entre composants et les points de fragilité. Le troisième est documentaire, incluant l’état de la documentation existante, les écarts avec le code réel et la capacité de reprise par une équipe tierce. Enfin, le quatrième est opérationnel englobe le processus de livraison, la gestion des incidents et les transfert de connaissances.
À l’issue d’un audit applicatif, vous disposez d’une cartographie précise de l’existant, d’une évaluation chiffrée de la dette technique et d’une estimation de l’effort nécessaire pour reprendre le projet en interne ou avec un nouveau partenaire. C’est le matériau indispensable pour prendre une décision éclairée et pour construire un plan de transition réaliste.
Un audit indépendant peut aussi objectiver un dysfonctionnement que le prestataire actuel refusait de reconnaître. Dans certains cas, le simple fait de commander un audit change la posture du prestataire et débouche sur une remise à niveau. Dans d’autres cependant, il confirme la nécessité de basculer.
Reprise de projet et reprise de code : basculer proprement
Quand la décision de changer est prise, la qualité de la bascule fait toute la différence. Une transition mal menée peut coûter plus cher que le statu quo. Une transition structurée transforme une situation difficile en opportunité de repartir sur des bases saines.
Deux cas de figure sont possibles selon votre situation. Tout d’abord, la reprise de projet concerne les projets encore en cours, non finalisés, où un prestataire doit être remplacé en cours de route. C’est une situation critique qui demande une prise en main immédiate et une capacité de conseil forte pour éviter que le projet ne dérive davantage.
Ensuite, la reprise de code concerne les applications déjà en production dont vous voulez confier la maintenance et l’évolution à un nouveau partenaire. Elle repose sur une méthode structurée incluant prise en main du code existant, remise à niveau de la documentation, mise en place de tests de non-régression et transfert de compétences vers la nouvelle équipe. L’objectif est de garantir que la continuité de service soit assurée pendant la bascule et que la nouvelle équipe soit autonome dans les meilleurs délais.
Cas client Socomat : la reprise d’un projet ERP critique
SOCOMAT, leader mondial de la location de réservoirs ISO pour gaz cryogéniques (40 ans d’expertise, 250 collaborateurs, plus de 9 000 équipements), avait engagé une refonte de son système de gestion financière sur Microsoft Business Central. Le projet s’était trouvé en situation critique et devait être repris en cours de route.
Nos équipes ont pris le relais dans ce contexte tendu. Elles ont modélisé un processus financier sur-mesure adapté au cycle de vie des conteneurs cryogéniques, centralisé les flux Achats, Ventes, Contrats et Finance dans une même interface, déployé un socle comptable multi-devise pour le contexte international du groupe, et automatisé les écritures comptables liées aux amortissements et à la facturation récurrente.
Le projet a été livré dans le budget défini, avec un déploiement agile en 4 mois grâce à une collaboration étroite avec les experts métiers de Socomat. Le verbatim de la direction générale résume la mission : « Hello Pomelo a repris notre projet dans une situation critique. Nous avons profité de la capacité de conseil des équipes d’Hello Pomelo pour reprendre et terminer le projet dans un budget défini. »
👉 Découvrir le cas client Socomat en détail
Cette mission illustre ce qui distingue une reprise réussie d’une bascule chaotique. Tout repose sur la capacité à mobiliser rapidement une expertise technique et métier, à cadrer un plan de reprise réaliste et à livrer dans les jalons annoncés. C’est précisément ce que doit apporter un partenaire quand vous décidez de changer de prestataire IT en cours de projet.
La maintenance applicative : pérenniser l’exploitation dans la durée
Une reprise de code ou de projet n’est que la première étape. La vraie question qui suit est celle de l’exploitation dans la durée. C’est le rôle de la maintenance applicative (ou TMA, Tierce Maintenance Applicative).
Toutes les prestations de maintenance applicative ne se ressemblent pas. Il y a d’un côté la maintenance corrective, qui se contente de résoudre les incidents et d’appliquer les patchs de sécurité. C’est un service basique, souvent contractualisé au ticket. De l’autre, il y a la maintenance évolutive, qui accompagne la roadmap métier et fait progresser l’application dans le temps. La maintenance évolutive est un vrai partenariat, pas un simple contrat de dépannage, allant des nouvelles fonctionnalités aux adaptations réglementaires et aux optimisations de performance.
Les indicateurs clés d’un bon contrat de maintenance applicative sont chiffrés et mesurables. La disponibilité garantie (typiquement 99,5% à 99,9% selon la criticité), le temps de garantie d’intervention (GTI) qui définit sous combien de temps le prestataire prend en main un incident, le temps de garantie de rétablissement (GTR) qui borne la durée maximale d’un incident, et le processus d’escalade en cas de dépassement.
Un bon partenaire en maintenance applicative se distingue également par sa capacité à faire vivre la documentation, à maintenir une équipe stable dans la durée et à proposer des évolutions plutôt qu’à attendre les demandes. C’est cette proactivité qui transforme un contrat de TMA en levier de performance IT.
Hello Pomelo : votre partenaire pour reprendre le contrôle
Décider de changer de prestataire IT, ce n’est pas seulement remplacer un fournisseur. C’est reprendre le contrôle de votre patrimoine applicatif, sécuriser la continuité de service et donner à votre SI les moyens de servir vraiment le métier.
Chez Hello Pomelo, nous accompagnons les responsables IT sur les trois étapes clés de cette bascule. D’abord l’audit applicatif pour objectiver la situation et construire un plan de transition chiffré. Puis la reprise de code pour prendre en main proprement un projet existant, avec la méthode structurée qui a fait ses preuves sur des missions comme Socomat. Et enfin la maintenance applicative pour assurer une exploitation stable et une évolution continue dans la durée.
Ces trois offres s’articulent en un parcours cohérent, calibré selon votre situation et votre niveau d’urgence. L’objectif est simple, transformer un moment de doute sur votre prestataire en opportunité de repartir sur des bases saines et pilotées.
Si vous vous reconnaissez dans plusieurs des signaux évoqués dans cet article, venez échanger avec nos experts pour identifier les points critiques de votre situation et les leviers à activer.
