Comment décider si le pilote autorise la migration ?

Dans l’ordre

1. Valider tâches critiques et retour
2. Étendre après recette signée
3. Arrêter ou réduire le projet si le critère éliminatoire échoue

Pourquoi ce choix

• Le succès d’une démonstration ne prouve pas la reprise
• Les propriétaires portent les conséquences
• Les promesses sont difficiles à comparer
• La démonstration doit produire une sortie vérifiable
• Ouvrir n’est pas reprendre
• Les échanges reviennent souvent vers l’ancien outil

Définir ce qui ne peut pas devenir moins bon

Demandez au responsable métier les tâches dont l’échec arrêterait le travail : envoyer depuis une adresse commune, corriger un document important, accéder à un dossier avec un partenaire ou reprendre une donnée à la prochaine période. Ne choisissez pas seulement les gestes faciles à démontrer.

Pour chacune, notez la personne qui l’accomplit, les données utilisées, le résultat attendu et la personne qui l’accepte. Ajoutez ce qui doit être refusé : un invité ne voit pas le dossier interne, une personne partie ne garde pas l’accès, une version ancienne ne devient pas la référence.

Notre recommandation est de commencer par quelques tâches décisives et les cas difficiles connus. Une grille immense que personne ne lit n’améliore pas l’acceptation. Si le périmètre ne comporte que de la lecture sans enjeu particulier, une recette plus courte peut suffire.

Écrire le critère de réussite avant de regarder le résultat

Remplacez « la collaboration fonctionne » par un résultat observable : une personne précise modifie la copie fictive, une autre retrouve sa correction et l’invité autorisé ouvre le bon document. Pour un calcul, le responsable donne la valeur attendue ; pour un courrier, le destinataire externe confirme réception et réponse.

Fixez aussi le seuil qui arrête l’essai. Une fuite de droits ou un résultat métier incorrect demande une correction avant extension. Une aide mal formulée peut être améliorée sans remettre en cause tout le service, si elle n’empêche pas la tâche et si le contournement reste acceptable. Le seuil doit correspondre à la conséquence réelle.

Si la preuve n’est pas disponible, écrivez « non testé ». Une capture envoyée par un fournisseur peut montrer une capacité générale ; elle ne remplace pas la réussite de votre parcours dans l’édition retenue.

Faire essayer par les personnes qui travailleront vraiment

Le groupe pilote doit représenter les difficultés du périmètre : propriétaire d’un contenu, utilisateur courant, partenaire externe et personne ayant besoin d’une aide technique quand ces rôles existent. Une personne qui connaît déjà tous les réglages peut masquer un parcours de récupération incompréhensible.

Utilisez des contenus fictifs ou des copies autorisées et maîtrisées. Faites reproduire la tâche sans guider chaque clic, puis demandez où la personne cherchera son travail la prochaine fois. Ce geste vérifie la continuité du parcours, pas seulement sa réussite avec l’administrateur à côté.

Notez l’appareil, le navigateur, l’édition, les rôles et la date. Une réussite sur ordinateur ne vaut pas automatiquement pour le téléphone ; un compte administrateur ne prouve pas les droits d’un utilisateur ordinaire.

Préparer une grille qui débouche sur une décision

La grille peut tenir dans un tableau simple : tâche, acteur, résultat attendu, preuve, écart et décision. Ajoutez une personne responsable et une prochaine action pour chaque écart. Gardez la référence du contenu et de la version testés.

Exemple fictif : une équipe reprend un dossier de devis. La modification et la lecture interne réussissent ; l’invité ne peut pas ouvrir le document qui lui est destiné. Le dossier n’est donc pas accepté pour le parcours externe. Nous corrigerions ce partage et réessaierions ce cas avant de déplacer les dossiers ayant le même besoin. La réussite interne reste une preuve de ce qui a été essayé, pas une validation de l’ensemble.

Cet exemple n’est pas le compte rendu d’un test. Il montre pourquoi une décision par usage est plus précise qu’un indicateur global de réussite.

Tester le retour avec le travail créé pendant le pilote

Avant l’extension, demandez ce qui arrive aux corrections et nouveaux documents si l’équipe revient au service précédent. Revenir à une copie d’avant l’essai peut perdre le travail récent. Faites donc identifier le lot à récupérer, son format et son propriétaire.

Sur un objet fictif, créez une modification dans le nouvel outil, récupérez-la puis faites-la lire ou poursuivre dans le parcours de retour. Si ce retour demande une conversion manuelle, mesurez cette limite et décidez si elle est acceptable pour la durée et le périmètre du pilote.

La possibilité de conserver temporairement le nouvel outil peut aussi faire partie du retour. Il faut alors garder ses comptes, son coût et son administration au budget ; ce n’est pas un retour sans dépendance.

Ne pas accepter les accès seulement à partir du cas positif

La CNIL recommande d’analyser les risques cloud, de configurer les permissions, de réaliser des sauvegardes et d’intégrer le cloud à la continuité et à la reprise d’activité. Pour le pilote, nous traduisons ces points en cas concrets : refus d’un accès interdit, retrait d’un compte et récupération d’un objet fictif si ce risque compte pour le projet.

Vérifiez aussi le titre ou l’extrait qu’une recherche pourrait révéler à tort. Une porte fermée au fichier ne prouve pas que toute information le concernant est cachée. Le protocole dépend de la surface réellement utilisée ; aucun incident n’a été simulé ici.

Un fournisseur peut documenter une fonction sans que votre équipe l’ait configurée correctement. Gardez la différence entre déclaration, configuration examinée et tâche effectivement réussie.

Étendre un lot accepté, sans transformer les inconnues en exceptions invisibles

Le responsable métier accepte les tâches ; l’administrateur confirme les droits et les conditions de reprise ; la personne qui porte le budget connaît les licences et interventions conservées. Adaptez ces rôles à l’organisation, sans inventer un comité.

Nous étendrions le lot dont les conditions sont remplies et garderions les autres en attente. Si un défaut touche un raccord commun, réexaminez les cas voisins : une erreur systémique ne reste pas un incident isolé parce qu’elle a été découverte dans un seul dossier.

Pour une exception tolérée, écrivez sa conséquence, la personne qui l’accepte et la prochaine date de décision. Une contrainte imposant la sortie peut changer le calendrier, mais elle ne rend pas le travail repris par définition.

Recontrôler le dernier changement avant la bascule

Entre le pilote et le lancement, le fournisseur, la configuration ou les contenus peuvent changer. Faites relire et réessayer les différences qui touchent une preuve décisive : autre édition, nouveaux droits, nouvelle procédure de copie ou objet absent du lot pilote.

Conservez le résultat final et la liste des écarts, puis annoncez où le travail doit continuer. Un ancien résultat positif n’est pas la preuve d’un texte, d’un réglage ou d’un lot modifié. La fermeture du service source reste une décision séparée, après reprise et conservation validées.

À vérifier

Guide de méthode, sans pilote exécuté, déploiement ni restauration testés. Exemple explicitement fictif. Les critères sont à adapter aux risques, usages, contrats et obligations applicables ; aucune preuve de compatibilité d’une offre n’est déduite de la méthode.

Preuves et sources

Les faits documentaires et déclarations sont distingués de nos avis et méthodes. Comment nous travaillons.