Le 8 octobre 2026, Microsoft a mis en preview publique un nouvel éditeur pour le Wiki d’Azure DevOps. Rien de révolutionnaire dans l’annonce — un composant d’édition qui change — mais le détail compte : c’est Monaco, le moteur qui fait tourner Visual Studio Code dans un navigateur, qui remplace l’ancien éditeur. Concrètement, ton Wiki de documentation interne récupère une partie de l’expérience d’édition que tu as déjà sur ton poste, sans rien installer.
Ce que Monaco change concrètement dans l’éditeur Wiki
La liste des ajouts tient en une poignée de points, mais chacun répond à une frustration précise de l’ancien éditeur :
- Coloration syntaxique du Markdown et numéros de ligne, comme dans VS Code — fini l’édition à l’aveugle sur un bloc de code imbriqué dans une liste.
- Recherche et remplacement natifs, directement dans la page en cours d’édition.
- Annuler et rétablir qui couvrent enfin le formatage, le collage, les pièces jointes et l’autocomplétion — pas seulement le texte brut.
- Autocomplétion déclenchée par caractère :
!pour une pull request,@pour une personne,#pour un item de travail, en plus des liens Wiki et des modèles de page. - Préférences persistantes pour le retour à la ligne automatique et le défilement synchronisé entre l’édition et l’aperçu.
Sur le papier, c’est un simple rattrapage : ce sont des fonctionnalités qu’un éditeur de texte sérieux propose depuis longtemps. Dans les faits, pour une équipe qui écrit sa documentation d’architecture, ses runbooks ou ses post-mortems directement dans le Wiki d’Azure DevOps plutôt que dans un outil externe, la différence entre corriger un formatage cassé à la main et un Ctrl+Z qui fonctionne vraiment change l’envie de documenter au jour le jour, pas seulement le confort.
Pourquoi Monaco précisément
Monaco est le composant d’édition open source que Microsoft a extrait de VS Code pour le réutiliser ailleurs — dans GitHub.dev, dans le Cloud Shell du portail Azure, et maintenant dans le Wiki. Réutiliser ce composant plutôt qu’un éditeur Markdown générique a un avantage direct : les raccourcis clavier, le comportement de l’autocomplétion et la gestion de la sélection multi-curseur te sont probablement déjà familiers si tu passes tes journées dans VS Code. Rien à réapprendre pour profiter du nouvel éditeur.
Activer la preview
Le nouvel éditeur se branche depuis le menu Preview features d’Azure DevOps, activable pour ton compte personnel ou pour toute l’organisation. Une fois activé au niveau organisation, il s’applique à toutes les pages Wiki sans distinction — pas de bascule page par page.
Microsoft ne communique encore aucune date de disponibilité générale ni de date de fin de preview. Les retours passent par les commentaires du billet officiel ou par le portail Developer Community, le canal habituel pour ce genre de requête produit chez Microsoft.
Ce que l’annonce ne couvre pas
Pas un mot sur l’aperçu Markdown en lui-même (il existait déjà avant Monaco et n’a visiblement pas changé), pas de liste d’extensions ou de support de diagrammes, et aucune mention de limitation connue à ce stade de la preview. Si ton Wiki contient beaucoup de tableaux Markdown complexes ou de blocs Mermaid, vérifie leur rendu avant de généraliser l’activation à toute l’organisation — rien dans le billet officiel ne garantit qu’ils aient été spécifiquement testés avec le nouvel éditeur.
Ce changement s’inscrit dans une tendance plus large sur Azure DevOps cette année : moderniser les interfaces historiques une par une plutôt que de tout refaire d’un coup. On l’a vu récemment avec la nouvelle page de couverture de code des Pipelines, et avec l’arrivée de l’IA dans la revue de pull requests via Copilot Code Review.
FAQ
Le nouvel éditeur Wiki est-il disponible sur Azure DevOps Server, la version self-hosted ?
L’annonce officielle ne mentionne qu’Azure DevOps Services, la version SaaS. Pour Azure DevOps Server, mieux vaut suivre les notes de version dédiées plutôt que de supposer une disponibilité simultanée.
Est-ce que j’ai besoin de droits d’administration pour l’activer ?
Pour toi seul, non — l’activation individuelle se fait depuis ton propre menu Preview features. Pour l’activer au niveau de toute l’organisation, il faut les droits d’administration d’organisation.
Le contenu Markdown existant est-il affecté par le changement d’éditeur ?
Non, seul le composant d’édition change. Le contenu Markdown stocké reste identique — tu peux désactiver la preview et retrouver l’ancien éditeur sans perte de contenu.
Si tu gères un Wiki volumineux, le plus simple reste d’activer la preview sur ton compte perso quelques jours avant de la proposer à toute l’équipe — le temps de vérifier que les pages les plus utilisées, runbooks et procédures d’astreinte en tête, s’affichent et s’éditent sans surprise. Les détails complets de l’annonce sont sur le billet officiel Azure DevOps Blog.
Laisser un commentaire