Microsoft le confirme avec ses propres chiffres (30 millions de sièges Copilot) : ce n'est plus l'adoption qui sépare les entreprises qui avancent — c'est l'adaptation métier par métier, ce qu'AppManager fait déjà par construction
Dans un billet du 30 juillet signé par son CMO « AI at Work », Microsoft publie ses propres données de télémétrie Copilot : 30 millions de sièges payants, une utilisation qui double d'année en année — et un aveu rare venant d'un éditeur : donner le même outil à tout le monde est le mauvais pattern. Ce que Microsoft ne dit pas, parce que ce n'est pas son rôle : la plupart des PME n'ont ni neuf ingénieurs ni un framework de tuning maison pour faire cette adaptation elles-mêmes.
Dans son billet du 30 juillet « The next measure of AI momentum is work transformed », Jared Spataro (Chief Marketing Officer, AI at Work chez Microsoft) publie des chiffres tirés directement de la dernière publication trimestrielle du groupe : Microsoft 365 Copilot dépasse 30 millions de sièges payants, avec un rythme d'ajout de sièges qui a plus que doublé d'un trimestre à l'autre, et un engagement hebdomadaire désormais comparable à celui d'Outlook ou Teams. Le billet documente aussi Copilot Cowork, un agent capable de boucler seul un cycle complet (planifier, exécuter, tester, corriger), construit par une équipe qui n'a jamais dépassé neuf ingénieurs et pourtant déjà utilisé par la moitié du Fortune 500 six mois après son lancement. Mais la phrase la plus importante du billet n'est pas un chiffre : « la différence entre les entreprises qui voient ce type de changement et celles qui attendent encore, ce n'est pas la largeur du déploiement — c'est la qualité de l'adaptation au travail réel ». Autrement dit : le pattern de déploiement le plus courant (donner le même outil à tout le monde) est explicitement présenté comme le mauvais pattern, par l'éditeur qui vend justement cet outil générique.
Le billet cite aussi deux cas concrets où l'automatisation reste sous contrôle humain explicite à grande échelle : l'Autonomous Sourcing Agent d'EY négocie avec les fournisseurs sur plus de 200 transactions réelles « tout en gardant les humains dans la boucle pour la validation et l'escalade » ; l'agent qualité d'Eaton a analysé environ 5 000 rapports de production « en gardant l'équipe d'experts d'Eaton au centre de chaque décision ». Ce sont exactement les mots qu'on utilise nous-mêmes depuis le premier module d'AppManager, pas une trouvaille de communication récente — sauf que ces deux cas opèrent à un volume (des milliers de transactions, des milliers de rapports) qu'une PME cliente d'AppH ne verra jamais, et n'a pas besoin de voir pour que le principe s'applique.
Pour AppH
- Le constat de Microsoft — s'adapter métier par métier plutôt que déployer un outil générique — décrit exactement l'architecture qu'AppManager a depuis le premier module : Dentaire, Optique, Kiné, Hôpital, Flotte, Spa, Tourisme, École ne partagent pas un même assistant recyclé, chacun a sa propre logique de statuts et d'actions.
- L'approbation humaine explicite avant qu'un agent agisse — le même principe qu'EY et Eaton appliquent à leur échelle — n'est pas une case ajoutée après coup chez AppH : c'est la condition par défaut de chaque module depuis sa conception, journalisée dans DECISIONS.md/l'audit trail, jamais une option qu'il faut activer.
Contre / ce qui ne s'applique pas
- Les chiffres cités (30 millions de sièges, neuf ingénieurs, Frontier Tuning) décrivent une capacité d'ingénierie interne que la quasi-totalité des PME n'a pas — ce n'est pas la preuve qu'une transformation équivalente est simple à obtenir sans une plateforme qui fait ce travail d'adaptation à la place du client.
- AppH ne construit pas d'équivalent à Microsoft Scout, l'agent « autopilote » qui reste actif en arrière-plan avec sa propre identité et ses propres permissions — chaque action d'AppManager attend une validation humaine explicite avant de s'exécuter, un choix de conception assumé, pas une fonctionnalité qui manque encore.
Ce qui nous frappe dans ce billet, c'est une honnêteté rare venant d'un éditeur qui vend justement l'outil générique dont il dit lui-même qu'il ne suffit pas : Microsoft admet que « donner le même outil à tout le monde » est le pattern qui ne fonctionne pas, et que ce qui crée de la valeur réelle, c'est l'adaptation métier par métier. On est d'accord — c'est littéralement pour ça qu'AppManager existe en modules séparés plutôt qu'en un seul assistant générique. Ce que le billet ne dit pas, parce que ce n'est pas le rôle de Microsoft de le dire : cette adaptation a demandé une équipe d'ingénieurs dédiée, un framework de tuning propriétaire (Frontier Tuning) et un système de contexte interne (Work IQ) qu'aucune PME ne construit seule un week-end. C'est exactement l'écart qu'AppH est censé combler — pas en promettant la même échelle que Microsoft, mais en livrant l'adaptation métier par métier sans exiger l'équipe d'ingénieurs pour l'obtenir. Et sur le contrôle humain : on note avec une honnêteté équivalente que garder un humain dans la boucle sur 200 transactions fournisseurs (EY) ou 5 000 rapports qualité (Eaton) est un exploit d'ingénierie à cette échelle — chez un client AppH, le même principe s'applique sur une poignée de décisions par semaine, pas par nécessité de rattraper la complexité après coup, mais parce que c'est la taille réelle du problème dès le départ.
Vérifié par un humain d'AppH