Changer de prestataire informatique sans casse

Cinq choses à sécuriser avant de donner congé

• L’accès administrateur à vos propres environnements. Votre locataire, votre pare-feu, votre console de sauvegarde. Pas partagé avec le prestataire, détenu par vous.
• La documentation et l’historique des tickets. Un export, dans un format lisible. L’historique vaut plus qu’on ne le pense, car il contient les problèmes récurrents.
• Les licences à votre nom. Les licences achetées via un prestataire et enregistrées à son nom sont, de loin, ce qui transforme le plus souvent une transition en négociation.
• Un registre des actifs conforme à la réalité. Numéros de série, dates de garantie, ce qui est loué et ce qui est possédé.
• Le préavis, par écrit. Lisez le contrat avant la conversation, pas après.

Ces cinq points s’obtiennent plus facilement tant que vous avez l’air d’un client satisfait qu’après avoir donné congé. Ce n’est pas du cynisme, c’est simplement ainsi que fonctionne un rapport de force.

Les trois phases d’une transition

La phase qu’on cherche à sauter est celle du doublon, généralement pour économiser. C’est la phase qui décide de la façon dont le changement sera retenu, car l’expérience utilisateur d’une transition se forme entièrement dans les deux premières semaines.

Sachez ce qui vous appartient vraiment

Trois catégories causent la quasi-totalité des litiges en fin de contrat. Les licences achetées via le prestataire et enregistrées sur son compte partenaire. Le matériel qui s’avère loué plutôt que possédé. Et les outils de supervision ou de sauvegarde qui appartiennent au prestataire, ce qui veut dire que votre historique part avec lui.

Rien de tout cela n’est nécessairement abusif, et une bonne part relève de la pratique courante. Cela ne devient un problème que si personne n’a vérifié dans quelle catégorie tombe chaque élément avant le congé. Posez la question maintenant, tant qu’elle est de routine et non une position de négociation.

La documentation est le vrai livrable

Une transition réussit ou échoue selon ce qui est écrit. Des mots de passe dans un coffre géré et non dans la tête de quelqu’un. Un schéma réseau qui correspond au bâtiment. Une liste des fournisseurs avec les dates de contrat. Quelles applications s’authentifient contre quoi.

Si le prestataire actuel ne peut pas produire cela, la partie entrante doit le reconstruire, et c’est ce coût qui rend une transition chère, pas la bascule elle-même. C’est aussi, soit dit en passant, le meilleur argument pour garder la documentation comme livrable vivant dans chaque contrat plutôt que comme obligation de sortie.

Quand changer est la bonne réponse, et quand non

Changez quand les mêmes problèmes reviennent sans que la cause de fond soit traitée, quand le reporting ne vous dit rien sur quoi agir, quand vous n’obtenez pas de réponse honnête sur ce qui a mal tourné, ou quand le prestataire a grandi au-delà de vous et que vous êtes devenu son plus petit client.

Ne changez pas à cause d’un seul mauvais incident. Tout prestataire connaît un mauvais mois, et le coût de la transition est réel. La question qui vaut la peine est de savoir si la réponse à l’incident a été honnête, car cela prédit mieux que l’incident lui-même.

Ce que nous faisons en reprenant

Nous commençons par l’inventaire, et nous disons clairement ce que nous trouvons, y compris ce que la partie précédente a bien fait. Cela compte, car un prestataire entrant qui critique tout prévoit généralement de tout vous revendre.

Ensuite une période en doublon, puis la bascule avec l’ancien canal ouvert quinze jours. La documentation est un livrable dès la première semaine et non une promesse, et le registre des actifs est reconstruit dans le cadre de la reprise plutôt que tenu pour acquis.

Ce que nous prenons en charge est décrit sous infogérance et service desk informatique, et le rythme des rapports sous gouvernance de service.