Pendant vingt ans, la manière la plus simple de faire dialoguer une application métier avec Microsoft 365, un ERP ou une base distante a été de lui donner un compte utilisateur et un mot de passe. Cette époque se referme. Entre l'authentification multifacteur devenue obligatoire chez Microsoft, la fin de vie des flux d'authentification par mot de passe et la durée de vie plafonnée des secrets applicatifs, beaucoup de PME découvrent la question le jour où un traitement nocturne s'arrête sans prévenir.

Ce qui a changé, et pourquoi vos applications sont concernées

Microsoft impose progressivement l'authentification multifacteur sur ses plateformes d'administration. La première phase, engagée à partir d'octobre 2024, a couvert le portail Azure, le centre d'administration Microsoft Entra et celui d'Intune, puis le centre d'administration Microsoft 365 à partir de février 2025. La seconde phase, démarrée le 1er octobre 2025, étend l'exigence aux opérations de création, de modification et de suppression réalisées via Azure CLI, Azure PowerShell, l'application mobile Azure, les outils d'infrastructure as code et les points de terminaison de l'API de gestion. Microsoft indique qu'il n'existe aucune possibilité de refus, seulement un report qui pouvait être demandé jusqu'au 1er juillet 2026 au plus tard.

À première vue, cela ne concerne que les administrateurs. En pratique, la règle vise tous les comptes utilisateurs qui effectuent ces opérations, y compris ceux qu'une entreprise a créés pour faire tourner un script ou une intégration. Un compte nommé svc-sauvegarde ou integration-erp reste, aux yeux de la plateforme, un compte utilisateur comme un autre. Le jour où l'exigence s'applique au locataire, il doit présenter un second facteur qu'aucun script ne saura fournir.

Le flux qui casse en premier

Le point de rupture technique porte un nom : le flux OAuth 2.0 dit ROPC, pour Resource Owner Password Credentials. C'est celui qui consiste à envoyer un nom d'utilisateur et un mot de passe pour obtenir un jeton. Microsoft précise qu'il est incompatible avec l'authentification multifacteur : une fois celle-ci active, les appels qui l'utilisent renvoient une erreur. Les bibliothèques suivent le même mouvement, avec la méthode AcquireTokenByUsernamePassword marquée obsolète dans la bibliothèque d'authentification Microsoft et la classe UsernamePasswordCredential dépréciée côté bibliothèques d'identité Azure.

Le symptôme est toujours le même chez nos clients : rien ne tombe en panne le jour de la mise en conformité. C'est trois semaines plus tard qu'un export comptable ne remonte plus, qu'une synchronisation d'annuaire s'interrompt ou qu'un connecteur SharePoint cesse d'écrire, sans message d'erreur visible par les utilisateurs. Les applications qui échouent silencieusement sont les plus coûteuses à rattraper, parce que personne ne sait depuis quand les données ne sont plus à jour.

Comment une application doit s'authentifier aujourd'hui

Le principe à retenir tient en une phrase : une application ne doit pas emprunter l'identité d'une personne. Elle doit disposer de sa propre identité applicative, avec ses propres droits. Trois options existent, par ordre de préférence.

  • L'identité managée, quand l'application tourne sur une ressource cloud du même fournisseur. Il n'y a alors ni secret ni certificat à stocker : la plateforme fournit le jeton. C'est la solution la plus sûre, parce qu'il n'y a rien à voler ni à renouveler.
  • La fédération d'identité, quand l'application s'exécute ailleurs mais peut prouver son origine, typiquement une chaîne d'intégration continue. Là encore, aucun secret durable n'est conservé.
  • Le principal de service avec certificat, puis avec secret en dernier recours. Le certificat est préférable au secret partagé, car il est plus difficile à recopier dans un fichier de configuration ou à envoyer par courriel.

Ces identités applicatives ne sont pas soumises à l'authentification multifacteur, précisément parce qu'elles ne sont pas des personnes. C'est tout l'intérêt de la bascule : elle rétablit une distinction que les habitudes avaient effacée.

Les secrets expirent, et personne ne prévient

Deuxième chausse-trappe, moins spectaculaire mais plus fréquente : les secrets applicatifs ont une durée de vie plafonnée. Chez Microsoft, un secret client ne peut plus être créé pour plus de 24 mois, et l'éditeur recommande une durée inférieure à 12 mois. Aucune notification automatique n'est envoyée à l'expiration si personne ne l'a mise en place. Un connecteur configuré tranquillement il y a deux ans s'arrête donc un matin, souvent chez un prestataire qui n'est plus au dossier.

La parade tient en trois gestes simples. Tenez une liste des secrets et certificats utilisés par vos applications, avec leur date d'expiration. Programmez une alerte 60 jours avant chaque échéance, adressée à une boîte partagée et non à une personne. Enfin, préparez la rotation en configurant deux identifiants valides en parallèle le temps de la bascule, ce que la plupart des plateformes autorisent : vous évitez ainsi la coupure entre l'ancien et le nouveau.

Par où commencer : l'inventaire en quatre colonnes

Avant de modifier quoi que ce soit, listez ce qui s'authentifie. Un simple tableau à quatre colonnes suffit et se remplit en une demi-journée dans une PME : quelle application ou quel script, avec quelle identité (compte nominatif, compte de service utilisateur, identité applicative), vers quel service, avec quel mode d'authentification et quelle date d'expiration.

Traitez ensuite par ordre de risque. En premier, les scripts qui tournent sous le compte nominatif d'un salarié, car ils s'arrêteront le jour de son départ et donnent à un traitement automatique tous les droits d'une personne. Ensuite, les comptes de service utilisateurs, à convertir en identités applicatives. Enfin, les secrets à échéance courte. Chaque conversion se teste sur un environnement séparé, avec un retour arrière possible, avant d'être appliquée en production.

Cinq erreurs que nous voyons régulièrement

  1. Le script lancé sous le compte du dirigeant, parce que c'est le seul compte qui a tous les droits. Il cumule le risque de sécurité et le risque de rupture.
  2. Le mot de passe du compte de service exclu de la politique de renouvellement pour que rien ne casse, ce qui revient à créer un identifiant permanent et non surveillé.
  3. Les secrets stockés dans le code source ou dans un fichier de configuration versionné, plutôt que dans un coffre dédié.
  4. Les droits recopiés d'un utilisateur, alors qu'une intégration n'a en général besoin que d'une portée très réduite, souvent en lecture seule.
  5. L'application dont l'identifiant appartient au prestataire et non à l'entreprise, ce qui pose un vrai problème le jour où l'on change de partenaire.

Questions fréquentes

Mon application interne est-elle concernée si elle n'utilise pas Azure ?

L'obligation Microsoft porte sur ses propres plateformes. Mais le mouvement est général : les principaux fournisseurs cloud durcissent l'authentification et les flux par mot de passe disparaissent progressivement partout. Si votre application stocke un mot de passe pour se connecter à un service tiers, la question se posera tôt ou tard.

Faut-il forcément réécrire l'application ?

Rarement. Dans la plupart des cas, le changement se limite au module d'authentification et à la configuration : on remplace un appel avec identifiant et mot de passe par une acquisition de jeton via une identité applicative. Le reste du code n'est pas touché.

Combien de temps prend une mise en conformité en PME ?

Cela dépend du nombre d'intégrations. Sur un parc de cinq à dix automatisations, comptez généralement quelques jours répartis sur deux à trois semaines, en incluant l'inventaire, les tests et la bascule progressive. C'est l'inventaire qui révèle les surprises, pas la technique.

Peut-on garder un compte de service utilisateur pour certains usages ?

C'est possible dans les périmètres non couverts par l'obligation, mais ce n'est pas souhaitable. Un compte utilisateur consomme une licence, brouille les journaux d'audit et donne à un automatisme les droits d'une personne. Autant profiter du chantier pour assainir.

Comment savoir si un traitement automatique est déjà en échec ?

Vérifiez les journaux de connexion de votre fournisseur d'identité et les journaux d'exécution de vos tâches planifiées. Un traitement qui ne remonte plus d'erreur mais ne produit plus de données depuis plusieurs semaines est le signal le plus courant.

Vous ne savez pas ce qui tourne réellement derrière vos applications métier ni sous quelle identité ? Nous réalisons cet inventaire et la bascule vers des identités applicatives sans interruption de service. Parlons de votre projet, ou découvrez notre approche des applications métier sur-mesure.