Dans la première partie de cet article, nous avons présenté AppCat, l’outil Microsoft qui analyse les applications .NET pour détecter leurs failles techniques et évaluer leur capacité à migrer vers Azure. Un assistant précieux, encore en évolution, pour accompagner la modernisation des applications.
Là où ça coince (encore)
AppCat est un outil précieux comme tout jeune berger numérique, il a encore des progrès à faire. Voici un tour d’horizon plus approfondi des limites constatées à l’usage, avec leurs justifications concrètes.
1. Un manque de contexte autour des incidents
Chaque incident est identifié par un code de règle (ex. : Security.0001), une courte description, et parfois un ou plusieurs liens vers la documentation Microsoft. Cela peut sembler suffisant en surface, mais à l’usage, on remarque plusieurs limites claires :
- Les intitulés sont souvent techniques et peu explicites. Par exemple, « Security.0001 » affiche « Utilisation de MD5/SHA1 détectée », sans indiquer s’il s’agit d’un usage critique ou périphérique, ni dans quel contexte c’est problématique.
- Les descriptions sont génériques et ne reflètent pas la gravité réelle dans votre application : utiliser MD5 dans une lib interne oubliée n’a pas le même impact que dans une couche de chiffrement d’API.
- Les liens vers la documentation ne sont pas contextualisés. Ils pointent vers des pages comme celle de SHA256 ou SHA512, mais ne justifient pas clairement pourquoi le lien est là, ni ce qu’il faudrait exactement faire dans le cas du projet analysé.
Les incidents sont donc listés mécaniquement, mais il manque une couche d’interprétation métier pour savoir si c’est un bug cosmétique ou un mur technique. Cela rend le travail d’analyse assez manuel pour les équipes, qui doivent naviguer à vue dans le JSON.
2. Difficile de prioriser intelligemment
AppCat fournit une liste d’incidents techniques, mais sans hiérarchisation métier ni plan d’action clair. Tous les incidents sont présentés de manière uniforme, qu’il s’agisse d’une incompatibilité majeure avec Azure ou d’une simple alerte de bonne pratique.
👉Exemple : un appel à une API critique non supportée sur App Service est listé de la même façon qu’une utilisation d’une méthode obsolète mais fonctionnelle. Cette homogénéité rend difficile la planification : faut-il traiter les incidents un à un, au hasard ? Ou tout faire en même temps ?
Cela dit, AppCat fournit tout de même certains indices utiles pour esquisser une priorisation technique :
- Chaque règle détectée inclut un niveau de sévérité (Mandatory, Recommended, Optional, Informational),
- Certaines règles sont accompagnées d’un champ « effort », exprimé sur une échelle (souvent de 1 à 3),
- Le rapport JSON contient un résumé global (summary.effort, summary.incidents) qui peut être exploité pour construire un scoring basique. Ce scoring n’est pas consolidé ni visuellement exploité dans l’interface, mais il permet à ceux qui le souhaitent d’établir une première cartographie technique de l’effort à fournir.
Cependant, AppCat ne tient pas compte du contexte métier : un incident sur un microservice interne est traité de la même façon que sur une application critique exposée en front. Il n’y a pas de notion de priorité fonctionnelle, de criticité utilisateur, ni de valeur métier embarquée.
De plus, il manque un regroupement thématique des incidents (sécurité, performance, compatibilité…), ce qui complique la construction d’un plan d’action structuré.
👉 Résultat : sans enrichissement externe ou surcouche d’analyse, AppCat reste un excellent détecteur… mais pas encore un véritable orienteur de priorités. Pour établir une feuille de route claire, les équipes doivent retraiter les résultats via des outils internes.
3. Multiprojets = galère annoncée
Contrairement à une idée reçue, AppCat peut analyser plusieurs projets techniques en une seule exécution, mais dans un cadre bien précis : si vous lui fournissez un fichier .sln (solution) ou un répertoire contenant plusieurs projets .csproj, il détectera et traitera l’ensemble. Le rapport final l’indiquera d’ailleurs dans le champ projects, avec le nombre total de projets analysés (par exemple : « projects »: 10).
Cependant, cela ne signifie pas qu’AppCat gère nativement un portefeuille applicatif au sens d’une suite d’applications métiers ou de solutions indépendantes.
Si vous souhaitez analyser plusieurs solutions .sln (par exemple, pour couvrir un ensemble d’applications), vous devez :
- Utiliser un script pour exécuter la CLI AppCat en boucle sur chaque fichier,
- Gérer manuellement les chemins d’entrée et les sorties JSON,
- Et éventuellement regrouper les rapports dans un outil externe pour les consolider.
👉 Exemple : un script PowerShell ou bash peut enchaîner plusieurs appels à appcat analyze, chacun avec un fichier .sln différent. Cela fonctionne bien, mais ce n’est pas pris en charge nativement dans AppCat : aucune option –multi ou –list n’existe.
Autre limite : même dans un rapport contenant plusieurs projets techniques, AppCat ne propose pas de regroupement par application logique, ni de tableau de bord global comparatif.
Pour les équipes de modernisation ou les architectes IT, cela implique :
- De créer des scripts batch pour passer en revue un grand nombre de solutions,
- De consolider les rapports dans des tableaux ou visualisations externes,
- De bâtir une logique d’agrégation et de comparaison.
En résumé : AppCat peut traiter plusieurs projets techniques à la fois dans une solution, et être orchestré pour enchaîner plusieurs analyses, mais il ne sait pas encore gérer ou restituer une vision multi-application complète. Avec les bons outils complémentaires ou les bonnes intégrations (CI/CD, reporting), on peut faire beaucoup. Mais cela confirme qu’AppCat, en l’état, est un analyseur unitaire plutôt qu’un moteur de transformation à large échelle.
Bientôt dans vos prés : des améliorations majeures
Face aux nombreuses limites relevées par les développeurs et architectes, Microsoft a commencé à enrichir AppCat en intégrant plusieurs améliorations,
certaines déjà en place, d’autres encore en cours de développement ou en preview.
Voici ce que la roadmap publique et les annonces officielles laissent entrevoir :
1. Meilleure classification des incidents
La classification des incidents dans AppCat a déjà commencé à évoluer. Si les premières versions utilisaient uniquement des noms de règles techniques (Security.0001, Compat.0023, etc.), les versions récentes affichent désormais des noms explicites, des catégories thématiques (comme Security, Local, Scale, etc.) et des niveaux de sévérité bien visibles (Mandatory, Optional, etc.).
Chaque règle appartient déjà à une famille fonctionnelle, ce qui permet de regrouper les problèmes par type d’enjeu (ex. : sécurité, compatibilité, performance). De plus, l’effort de correction est parfois renseigné, et les résultats sont exportables sous forme structurée (JSON ou HTML).
Il reste toutefois des marges d’amélioration attendues, notamment :
- Un regroupement plus lisible dans l’interface Visual Studio ou les rapports HTML,
- Une navigation filtrable par thème métier,
- Et à terme, une présentation qui facilite les arbitrages entre domaines critiques (par exemple : corriger les failles de sécurité avant les problèmes de performance).
Autrement dit, AppCat a déjà posé les fondations d’une classification intelligente, mais cette logique gagnerait encore à être renforcée dans l’UX des outils connectés. : aujourd’hui, elles sont uniquement techniques. Demain, elles seront sans doute regroupées par thématique (sécurité, compatibilité, performance, etc.), ce qui facilitera la lecture et la priorisation.
2. Enrichissement des liens documentaires
Actuellement, les liens fournis dans les rapports AppCat sont généralement très ciblés : ils renvoient souvent vers une classe .NET (comme SHA256 ou ConfigurationManager) ou vers une documentation technique assez générique. Bien que ces références aient leur utilité, elles manquent souvent de contexte applicatif, d’exemples pratiques, ou de scénarios concrets pour guider l’utilisateur.
Microsoft prévoit donc d’enrichir ces liens pour les rendre plus pertinents, plus narratifs et plus actionnables. Cela passerait par :
- Des articles de documentation contenant des cas d’usage concrets
- Des guides de migration spécifiques à certaines technologies ou frameworks
- L’ajout de contenu pédagogique (code avant/après, alternatives proposées)
- Un meilleur balisage des règles dans les liens pour expliquer pourquoi cette doc est pertinente à cet endroit précis
👉 Exemple : au lieu de simplement pointer vers la classe SHA256, un lien pourrait renvoyer vers une page expliquant pourquoi SHA1 est risqué, comment refactorer une méthode existante, et quelles bibliothèques modernes utiliser à la place avec des extraits de code et des diagrammes de décision.
Ce type d’enrichissement ferait gagner beaucoup de temps aux équipes, tout en rendant le rapport AppCat bien plus exploitable sans devoir chercher la bonne interprétation ailleurs sur le web, dans la documentation Azure, avec des exemples et des scénarios d’usage, pour aller au-delà de la simple référence à une classe .NET.
3. Intégration dans Azure Migrate
Bien qu’AppCat fonctionne actuellement comme un outil autonome, Microsoft a exprimé son intention de le connecter plus directement à Azure Migrate, le portail central de stratégie de migration cloud. Cette intégration viserait à offrir une expérience unifiée entre l’analyse applicative (via AppCat) et la cartographie d’infrastructure (via Azure Migrate).
Aujourd’hui, ces deux univers, code et infrastructure, sont encore traités séparément. Azure Migrate propose des outils puissants pour évaluer les machines virtuelles, les bases de données et les dépendances réseau, mais il n’analyse pas le code source des applications. AppCat comble ce vide, mais ses résultats sont isolés dans des rapports locaux, non visibles depuis le portail Azure.
Avec une intégration native, on pourrait imaginer :
- Une vue consolidée des risques infrastructurels et applicatifs sur un même tableau de bord
- Des rapports corrélés, indiquant par exemple si une machine contenant une app legacy critique est également à risque du point de vue code
- La possibilité de lancer AppCat depuis Azure Migrate, avec gestion des résultats et historiques centralisés
Cette perspective ouvre la voie à un AppCat mieux intégré dans les parcours de migration Azure, plus visible, plus gouvernable, et surtout, mieux aligné avec les processus d’entreprise.
En résumé, AppCat évolue vite. Si aujourd’hui il reste un outil brut, demain il pourrait devenir un véritable assistant de migration intelligent, interactif et intégré. À condition de garder le cap… et d’écouter les bêlements des utilisateurs, ce qui permettrait de combiner diagnostic applicatif et stratégie d’infrastructure dans une même interface.
Je l’ai testé pour vous : naissance du Moutonator9000
À force de jongler avec les rapports JSON d’AppCat, une idée a germé : et si on rendait ces données plus digestes ? Plus ludiques ? Plus… moutonnesques ? Ainsi est né Moutonator9000 🐑, un projet personnel conçu pour démontrer tout le potentiel d’AppCat tel qu’il existe aujourd’hui, sans attendre les évolutions futures.
L’objectif n’était pas de faire un outil d’entreprise ou un produit commercial, mais un prototype narratif et pédagogique, dont le but est triple :
- Illustrer la puissance actuelle d’AppCat,
- Souligner l’importance de la restitution visuelle et humaine,
- Et… rendre la tech plus drôle et mémorable.
L’idée de départ était de « Migrer des applis .NET legacy vers Azure… en les transformant en moutons caractériels. ». Chaque mouton incarne une application .NET legacy analysée par AppCat. Grâce à un moteur de transformation interne appelé SheepEngine, les rapports JSON sont traduits en portraits narratifs : un nom de mouton, une personnalité, une gravité, un ensemble de technologies détectées, et une cible Azure recommandée.
Ce projet repose sur une mini-architecture modulaire composée de :
- 10 mini projets legacy .NET (LegacyApps/) représentant divers cas (WebForms, WCF, MVC, etc.)
- Un analyseur AppCat CLI générant des fichiers .json
- Le module SheepEngine pour créer le profil du mouton, incluant un calculateur de score fait à partir des résultats AppCat etattribuant un certain nombre de points en fonction du nombre d’incidents trouvés, de leur catégorie (Security, Scale, etc) et de leur criticité selon AppCat.
- Un dashboard Blazor pour explorer et filtrer les moutons (vue grille, dark mode, animations, etc.)
- Un générateur de rapports narratifs Markdown + PDF.
- Et enfin, un Chaos Mode™ pour simuler en masse la migration de centaines d’applis fictives
Fonctionnalités clés
| Fonction | Détail |
|---|---|
| Analyse via Appcat | Génère des rapports JSON depuis de vraies applis |
| Génération de personnalité | Interprétation humoristique des technos détectées |
| ️ Suggestion de cible Azure | App Service, AKS, Container Apps… selon les résultats |
| Dashboard visuel | Liste interactive des moutons et de leurs caractéristiques |
| Rapport de migration | Généré automatiquement par mouton (Markdown / PDF) |
| Score de priorité de migration | Calculé selon la sévérité, le volume d'incidents et les dépendances critiques |
| Recommandation de service Azure | Automatisée selon les règles AppCat détectées et les patterns techniques |
| Chaos Mode™ | Génération de 100 moutons aléatoires avec logs délirants |
| Simulation BDD | Ajout de dépendances fictives à des bases SQL / Access |
Exemple de fiche générée
Décryptage de la fiche :
- Nom du mouton : MVCMichel5126
Le nom reflète la technologie principale (MVC) et ajoute une touche de personnalité par un prénom généré aléatoirement suivi d’un identifiant. Cela permet une identification rapide tout en injectant un brin d’humour. - Personnalité : Leader confiant
Ce profil est attribué aux applications qui, malgré quelques limitations techniques, reposent sur des frameworks relativement modernes comme ASP.NET MVC. L’app est “confiante” car ses fondations sont solides, son architecture relativement bien structurée, et son niveau de risque souvent intermédiaire. Le côté “leader” peut aussi refléter une place importante de l’application dans l’écosystème. - Technologies : MVC
L’outil a détecté une application construite sur ASP.NET MVC. Bien que cette technologie soit antérieure à .NET Core, elle est souvent plus simple à moderniser que WebForms ou WCF. C’est une bonne base pour envisager une transition cloud, surtout si le code est propre et découplé.
- Trust Score : 42%
Ce score reflète une compatibilité cloud encore limitée, probablement à cause d’incidents techniques modérés : dépendances obsolètes, appels API non compatibles, ou configuration datée. Ce n’est pas catastrophique, mais il faudra prévoir des ajustements. La présence d’une base de données Oracle pèse sûrement dans le score. - Cible Azure : Azure App Service
AppCat a suggéré cette plateforme comme cible potentielle. Cela suppose que l’application est majoritairement web, sans dépendances système bloquantes, et peut être packagée pour tourner dans un environnement managé PaaS. Attention : il faudra veiller à la compatibilité avec Oracle.
- Base de données : Oui (Oracle Database)
Le moteur détecte ici une dépendance à une base Oracle. Cela complexifie légèrement la migration, car Oracle n’est pas nativement pris en charge dans tous les services Azure. Il faudra prévoir une stratégie spécifique : par exemple, conserver Oracle en IaaS, ou envisager une migration vers Azure Database for PostgreSQL si c’est possible.
Chaque fiche devient donc une carte d’identité synthétique pour guider les discussions entre développeurs, architectes et décideurs non techniques. Le tout, avec une touche d’humour qui facilite la mémorisation.
Objectifs pédagogiques
- Sensibiliser aux risques techniques d'un portefeuille applicatif .NET avant migration
- Illustrer par l'absurde mais le concret ce que AppCat détecte réellement
- Susciter l'adhésion des parties prenantes non techniques grâce à une approche décalée
- Favoriser la discussion autour des stratégies de migration en rendant les rapports lisibles, partageables, et amusants
C'est un projet fun, mais structuré. Codé en sprints courts avec backlog Azure DevOps, il respecte un plan clair, intègre des composants gratuits (AppCat, Visual Studio, bibliothèques open source) et peut être répliqué par n'importe qui voulant explorer AppCat autrement.
En somme, Moutonator9000 est un hommage, un outil de vulgarisation, et une forme de plaidoyer : le legacy ne doit pas être honteux : il peut être drôle, assumé, et transformable.
Pour conclure
AppCat, aujourd’hui, est bien plus qu’un prototype ou un simple utilitaire de scan. C’est un outil fiable, maintenu activement par Microsoft, qui trouve sa place dans toute démarche de modernisation .NET vers Azure. Il fournit des diagnostics clairs, des recommandations concrètes, et s’intègre dans les environnements de développement modernes (Visual Studio, GitHub Actions, CLI). Son efficacité repose sur sa simplicité : il fait peu de choses, mais les fait bien.
Mais ce qui le rend particulièrement prometteur, c’est sa capacité à évoluer rapidement. La roadmap annoncée par Microsoft est ambitieuse : enrichissement des liens documentaires, visualisations HTML, recommandations ciblées selon le service Azure visé, et même intégration future dans Azure Migrate. AppCat ne cesse de s’améliorer, et tout indique qu’il pourrait devenir à terme un véritable assistant de migration intelligent, intégré et interactif.
Cependant, sa force actuelle peut être décuplée lorsqu’on l’augmente — non pas pour corriger ses lacunes, mais pour lui ajouter de la lisibilité, de l’impact et du sens métier. C’est là que des projets comme le Moutonator9000 prennent le relais : en transformant les rapports techniques en récits partageables, compréhensibles par tous, et utiles dans des arbitrages de gouvernance.
Car migrer, ce n’est pas simplement déplacer du code. C’est comprendre, prioriser, décider. C’est faire le lien entre le diagnostic technique et la vision produit. Et parfois, pour cela, il faut un outil qui sache parler développeur, manager, DSI, etc.
AppCat vous donne les faits. Le reste : la mise en forme, la pédagogie, et la stratégie vous appartient.
