Calipia : le blog

Il y a des annonces de fin de vie qui passent inaperçues parce qu’elles ne concernent qu’un utilitaire oublié. Celle de Microsoft Whiteboard n’entre pas tout à fait dans cette catégorie. D’abord parce que l’outil est réellement utilisé, en atelier d’architecture comme en rétrospective agile. Ensuite parce que l’opération cumule trois mouvements distincts que Microsoft a communiqués séparément, avec des dates qui ont changé en cours de route, et une documentation qui n’a pas suivi partout au même rythme. Résultat : beaucoup de DSI croient que quelque chose s’est déjà passé, alors que l’essentiel reste devant elles.

Remettons donc les pendules à l’heure, puisque c’est visiblement nécessaire.

Un calendrier qui a glissé de six semaines

Le plan initial prévoyait la fin de l’outil de migration au 22 août 2026, la suppression définitive des tableaux non migrés au 5 septembre, et la dépréciation des applications autonomes au 14 septembre. Fin août, Microsoft a repoussé l’ensemble. Le calendrier en vigueur est désormais le suivant.

Jusqu’au 25 septembre 2026, la migration des tableaux blancs stockés sur Azure vers OneDrive reste possible, y compris les relances après échec. Le 25 septembre, l’outillage de migration disparaît et les tableaux Azure restants basculent en lecture seule. Ils demeurent consultables et exportables, mais figés.

Le 16 octobre 2026, deux choses se produisent simultanément. Les tableaux Azure non migrés sont supprimés définitivement, sans possibilité de récupération, et les applications autonomes Whiteboard pour Windows, iOS et Android cessent d’être prises en charge. Les applications déjà installées ne sont pas désinstallées automatiquement : elles affichent un écran de fin de service à la place de la galerie de tableaux, ce qui promet quelques tickets au support interne de la part d’utilisateurs persuadés d’avoir perdu leur travail.

Le 30 novembre 2026, le service Whiteboard adossé à Azure est arrêté pour de bon.

Un détail amusant pour qui aime la cohérence documentaire : au moment où ces lignes sont écrites, la page de support consacrée à la migration mentionne encore le 14 septembre comme date de retrait des applications autonomes, et le 22 septembre comme limite de déclenchement de la migration depuis l’application Windows. La page dédiée au retrait, mise à jour le 24 août, annonce quant à elle le 16 octobre. Deux articles de support, deux vérités. On notera aussi que le Message Center a d’abord parlé du 30 novembre pour la dépréciation de l’application, avant qu’un message de suivi ne fixe le 16 octobre.

Ce qui disparaît vraiment, et ce qui reste

Il faut être clair sur le périmètre, car les titres anxiogènes ont circulé. Microsoft Whiteboard, en tant que service, ne ferme pas pour les comptes professionnels et scolaires. Ce qui disparaît, ce sont les trois clients natifs : Windows, iOS et Android.

Pour un compte d’entreprise, les points d’entrée restants sont Whiteboard sur le web, l’application Whiteboard dans Teams, le tableau blanc dans une réunion Teams, l’onglet Whiteboard dans une conversation Teams, et l’accès aux fichiers .whiteboard directement depuis OneDrive. Les tableaux adossés à OneDrive ne sont ni supprimés ni dégradés par le retrait des applications.

Pour un compte Microsoft personnel, en revanche, la sortie est nettement plus sèche. L’expérience grand public s’arrête, et l’utilisateur qui tient à ses contenus doit les exporter avant l’échéance. On retiendra au passage qu’un abonnement Microsoft 365 Personnel ou Famille ne vaut pas compte professionnel éligible, nuance qui va décevoir quelques indépendants.

Le vrai sujet technique : une migration pilotée par l’utilisateur

C’est ici que le dossier devient intéressant pour un architecte. Depuis 2022, les nouveaux tableaux blancs des clients commerciaux sont stockés dans OneDrive. Les tableaux créés avant cette bascule sont restés dans un stockage Azure propriétaire, avec les limitations que cela implique en matière d’historique de version, d’eDiscovery et de gouvernance. Le mouvement de fond, ce n’est donc pas l’abandon d’une application, c’est l’alignement du dernier îlot de stockage résiduel sur le socle OneDrive et SharePoint.

Le problème est dans la mécanique. La migration n’est pas une opération pilotée côté tenant par Microsoft. Elle se déclenche lorsque le propriétaire du tableau ouvre Whiteboard depuis un client éligible, c’est-à-dire le web ou Teams. Autrement dit, un tableau appartenant à un collaborateur parti de l’entreprise, en congé longue durée ou simplement peu enclin à ouvrir un outil qu’il n’utilise plus ne migrera jamais tout seul. Les applications mobiles, elles, ne déclenchent rien du tout.

Microsoft fournit heureusement un module PowerShell, WhiteboardAdmin, qui constitue la seule voie sérieuse pour traiter le sujet à l’échelle. Get-WhiteboardsForTenant permet l’inventaire, Get-WhiteboardOwners l’identification des propriétaires, Get-WhiteboardMigrationMapping la correspondance entre ancien et nouveau tableau, Set-WhiteboardOwner et Invoke-TransferAllWhiteboards le transfert de propriété vers un compte actif capable de déclencher la migration, Export-WhiteboardHtml l’export de secours. Restore-Whiteboard autorise enfin la restauration d’une version Azure d’origine pendant environ quatre-vingt-dix jours après migration, mais jamais au delà du 16 octobre.

Deux réserves méritent d’être soulignées. La première est que les données d’inventaire sont précalculées et peuvent accuser environ deux semaines de retard, ce qui rend l’exercice de pilotage un peu sportif à trois semaines de l’échéance. La seconde est que ces commandes n’offrent pas de migration centralisée : elles préparent le terrain, elles ne font pas le travail. Microsoft le reconnaît d’ailleurs explicitement dans sa documentation, ce qui a le mérite de la franchise.

Ajoutons les causes d’échec les plus banales, qui sont aussi les plus fréquentes en production : un OneDrive saturé, un OneDrive non provisionné, une licence absente. Trois motifs qui n’ont rien d’exotique dans un parc de plusieurs milliers de comptes, et qui supposent une boucle de remédiation avec les équipes poste de travail et licensing.

Ce qu’une DSI devrait avoir fait avant le 25 septembre

L’ordre de priorité tient en peu de lignes. Lancer l’inventaire des tableaux Azure résiduels et identifier leurs propriétaires. Transférer la propriété des tableaux orphelins vers des comptes actifs. Notifier les utilisateurs concernés en leur expliquant qu’il suffit d’ouvrir Whiteboard depuis Teams ou le web, et surtout pas depuis le mobile. Exporter ce qui refuse obstinément de migrer.

Il reste ensuite le volet poste de travail, souvent négligé dans ce type d’opération : retirer l’application des catalogues Intune et des images de référence, purger les liens d’installation dans le portail interne, mettre à jour les scripts de support et les supports de formation, et vérifier les documents d’onboarding qui pointent encore fièrement vers une application qui n’ouvrira plus rien.

Un point mérite par ailleurs d’être clarifié auprès de votre interlocuteur Microsoft si vous exploitez un parc de Surface Hub ou de salles équipées, car la communication officielle porte sur les clients Windows, iOS et Android sans traiter explicitement ces scénarios de salle. Mieux vaut poser la question maintenant que le découvrir en réunion de comité de direction.

La lecture stratégique : Teams comme unique surface

Ce retrait s’inscrit dans une trajectoire parfaitement lisible. Skype for Business absorbé par Teams, Yammer devenu Viva Engage, Stream Classic transféré vers SharePoint, Kaizala éteint. À chaque fois la même logique : une capacité fonctionnelle survit, l’application qui la portait disparaît, et le contenu rejoint le socle commun OneDrive et SharePoint.

Il y a de vraies bonnes raisons à cela. Une seule surface d’authentification, un seul modèle de permissions, une gouvernance unifiée, la rétention et l’eDiscovery qui s’appliquent enfin sans dispositif spécifique, et une seule pile à maintenir côté éditeur. Pour un RSSI, la disparition d’un stockage Azure propriétaire échappant aux politiques de rétention est objectivement une bonne nouvelle.

Il y a aussi un coût. Chaque application autonome retirée renforce la dépendance à un client unique dont les incidents deviennent mécaniquement plus structurants. Un tableau blanc devient une fonctionnalité de Teams, donc soumis à ses conditions de disponibilité, à ses performances et à ses plans de reprise. L’usage hors connexion, la réactivité au stylet sur les grands formats et la simplicité d’un client natif étaient précisément les arguments qui justifiaient l’existence d’une application dédiée. Ils passent par pertes et profits.

Pour les organisations qui avaient fait de Whiteboard un outil d’animation d’atelier à part entière, la question de l’alternative se pose légitimement, avec des acteurs comme Miro, Mural, FigJam ou des solutions souveraines selon les contraintes de localisation des données. Pour celles qui ne l’utilisaient qu’en réunion Teams, l’événement est un non-événement, ce qui est probablement le cas le plus fréquent et explique la relative discrétion de l’annonce.

En résumé

Le retrait des applications autonomes est l’arbre. La migration Azure vers OneDrive est la forêt, et c’est elle qui porte le risque de perte de données irréversible au 16 octobre. Une DSI qui ne retiendrait qu’une seule action de cet article devrait retenir celle ci : lancer Get-WhiteboardsForTenant aujourd’hui, pas le 24 septembre au soir.

Quant à la leçon générale, elle est connue mais toujours utile à rappeler en comité d’architecture : dans l’écosystème Microsoft, une application autonome est un état transitoire, rarement une destination…