Application Power Platform héritée : audit et maintenance

Le scénario se produit chaque mois dans une PME quelque part. Une application Power Apps gère les demandes de congés, ou les devis, ou les contrôles qualité. Elle a été construite par un alternant, un collègue passionné ou un prestataire, il y a deux ans. La personne est partie. Ce matin, un flux Power Automate a échoué, personne ne sait pourquoi, et la seule documentation est un fichier de notes sur un OneDrive auquel plus personne n'a accès.

Rien de dramatique, à condition de ne pas bricoler. Une application héritée se reprend avec une méthode : un audit court, un transfert propre, puis une maintenance d'application Power Platform qui a un nom, un canal et un délai.

L'audit : ce qu'on regarde

Quelques jours suffisent pour une application de taille normale et ses flux. Pendant l'audit, on ne réécrit rien, on regarde.

1. Inventaire : les applications, les flux, les environnements, les listes SharePoint ou les tables Dataverse, les rapports Power BI qui en dépendent. On est souvent surpris : l'application de congés a trois flux, dont un que personne n'avait vu.
2. Propriétaires : qui possède chaque objet, qui peut le modifier, qui est co-propriétaire. Une application dont le seul propriétaire est un compte désactivé est une bombe à retardement.
3. Connexions : chaque flux tourne avec les connexions de quelqu'un. Si ce quelqu'un est parti, ses connexions cessent de fonctionner avec son compte, et le flux s'arrête. C'est la cause numéro un des échecs qu'on nous appelle à réparer.
4. Licences : l'application utilise-t-elle Dataverse ou un connecteur premium ? Est-ce que tout le monde a la bonne licence, ou est-ce que ça tenait par un essai gratuit ?
5. Points de fragilité : identifiants codés en dur, liste SharePoint qui approche les 5 000 éléments, formules illisibles, flux sans gestion d'erreur, absence de solution ou de sauvegarde.

L'audit se termine par un rapport d'une dizaine de pages, avec une note par point : vert, à surveiller, à corriger vite.

Documenter, transférer les accès, surveiller les flux

La documentation minimale tient sur une page par application : à quoi elle sert, qui l'utilise, où sont les données, quels flux en dépendent, quelles connexions et quels comptes, ce qui casse si tel élément change. Rien de plus. Une documentation de cinquante pages n'est jamais lue ni mise à jour.

Le transfert des accès suit une règle simple : jamais une seule personne. Deux co-propriétaires sur chaque application et chaque flux, dont un en informatique. Les connexions des flux critiques basculent sur un compte de service dédié, avec un mot de passe géré par l'informatique, pour que le prochain départ ne casse rien.

Puis la surveillance : les notifications d'échec de Power Automate doivent arriver dans une boîte que quelqu'un lit, pas dans la messagerie de l'ancien collègue. Un flux de contrôle qui recense chaque matin les exécutions en échec de la veille et les poste dans un canal Teams prend une heure à mettre en place. Il évite de découvrir un problème deux semaines après.

Le canal d'assistance et le plan d'évolution

Une application maintenue a une adresse. Un canal Teams ou une boîte mail où les utilisateurs signalent un problème, un délai de première réponse annoncé, et un journal des incidents avec leur résolution. C'est exactement ce que couvre notre offre de maintenance Power Platform : un forfait mensuel, des délais garantis par contrat, un consultant senior qui connaît votre application.

Le plan d'évolution est une liste, revue chaque trimestre : ce que les utilisateurs demandent, ce que l'audit a signalé, ce que Microsoft change (un connecteur qui disparaît, une limite qui bouge). On priorise, on chiffre, on livre par petits lots. Une application qui n'évolue pas meurt lentement ; une application qui évolue sans plan casse vite.

Quand il vaut mieux reconstruire

Parfois, l'audit conclut qu'il ne faut pas réparer. Les signaux qui ne trompent pas :

• Les données vivent dans un fichier Excel sur le OneDrive personnel de quelqu'un, et l'application lit ce fichier.
• La logique métier est répartie entre l'application, six flux et deux formules Excel, sans que personne ne puisse dire qui fait quoi.
• Chaque correction en casse deux autres.
• Le besoin a changé : l'application gère 40 % de ce que l'équipe fait vraiment, le reste est revenu sur papier.

Dans ce cas, on garde l'application en vie le temps de reconstruire sur une base propre, avec le même cadrage que pour une application neuve : voir notre méthode et l'offre de réalisation au forfait. La règle de décision est financière : si le coût estimé des corrections dépasse la moitié du coût d'une reconstruction, on reconstruit.

Une application héritée n'est pas un problème, c'est un actif mal documenté. Un état des lieux, inclus dans notre maintenance, vous dit ce que vous possédez vraiment et ce qu'il faut sécuriser en premier. Le point de départ le plus simple est un échange de trente minutes pour décrire ce qui tourne chez vous.