Power Apps ou développement sur Azure : où passe la frontière
C’est l’arbitrage le plus structurant d’un projet d’outil métier, et il se prend presque toujours trop tard — après avoir choisi un prestataire, qui a naturellement proposé ce qu’il sait faire. Or les deux voies ne coûtent pas la même chose, ne vivent pas la même durée, et ne se rattrapent pas de la même façon quand on s’est trompé.
Les deux voies, en une phrase chacune
Power Apps assemble un outil à partir de briques existantes : un formulaire, une liste, des droits, une base de données, des connexions vers vos autres systèmes. Vous ne construisez pas la plomberie, vous décrivez le métier.
Un développement sur Azure part d’une page blanche et bâtit exactement ce qu’il faut. Vous construisez la plomberie, et vous en devenez propriétaire — avec ce que cela suppose de liberté et de responsabilité.
Aucune des deux n’est le haut de gamme de l’autre. Ce sont deux réponses à deux situations.
Les cinq questions qui décident
Qui utilise l’outil ? Des collaborateurs de l’entreprise, identifiés dans votre annuaire : Power Apps est chez lui. Des clients, des candidats, un public large et non authentifié : la question bascule, parce que le modèle de licence de la plateforme est pensé pour des utilisateurs internes.
Combien de personnes en même temps ? Quelques dizaines, quelques centaines : la plateforme suit sans réfléchir. Des milliers de sessions simultanées, ou des pics violents et courts : c’est un sujet d’architecture, et il se traite sur Azure.
Que doit faire l’outil que rien ne sait faire ? Un calcul métier particulier, un algorithme d’optimisation, un traitement d’images, une intégration avec un équipement industriel. Ce n’est qu’un exemple parmi d’autres, mais le principe tient : dès qu’il y a un cœur que personne n’a écrit avant vous, il faut l’écrire, et il vit mieux sur Azure.
Quelle est la durée de vie attendue ? Un outil qui accompagne un processus appelé à changer tous les six mois gagne à être fait dans un environnement où l’on modifie vite. Un socle qui doit durer dix ans et porter d’autres outils mérite d’être construit comme un socle.
Qui le fera évoluer dans trois ans ? Une équipe interne qui connaît le métier peut reprendre une application Power Apps. Un développement sur mesure demande un développeur — le vôtre, ou un prestataire. Cette réponse-là engage plus que le budget initial.
Remarque : les deux voies ne s’excluent pas. Le cas le plus fréquent, et le plus solide, est mixte : l’interface et le circuit de validation dans Power Apps, le traitement lourd sur Azure, les deux reliés par un service. On garde la rapidité d’un côté et la maîtrise de l’autre.
Se tromper de côté, et ce que ça coûte
Trop de sur-mesure. Une entreprise fait développer un outil complet là où l’assemblage aurait suffi. Elle paie l’écriture, puis l’hébergement, puis la maintenance, puis les mises à jour de sécurité de composants qu’elle n’a pas choisis — et elle devient dépendante de celui qui l’a écrit.
Trop d’assemblage. Une entreprise force la plateforme à faire ce qu’elle ne sait pas faire. L’outil sort, il fonctionne mal, il devient lent, et chaque correction en casse une autre. C’est le symptôme le plus fiable d’une erreur de frontière, et il apparaît en général au moment de la montée en charge.
Dans les deux cas, le rattrapage coûte plus que ce qu’aurait coûté le bon choix au départ. C’est pourquoi cette question se pose avant de choisir qui construit.
Ce que l’un et l’autre partagent, et qui compte
Quel que soit le côté de la frontière, l’outil s’appuie sur la même identité, les mêmes droits, la même journalisation, les mêmes règles de sécurité que le reste de votre système d’information. C’est vrai pour une application Power Apps comme pour une application hébergée sur Azure. Un décideur peut donc trancher sur le métier et sur l’usage, sans craindre que la gouvernance diverge selon la réponse.
Ce qu’il faut faire
- Répondez aux cinq questions avant de rencontrer un prestataire.
- Écrivez en une page ce que l’outil doit faire, et surtout ce qu’il ne fera pas.
- Demandez explicitement à qui vous consultez de justifier son côté de la frontière.
- Si la réponse est « les deux », demandez où passe la couture — c’est là que se jouent les ennuis.
- Prévoyez qui reprendra l’outil dans trois ans, et vérifiez que ce choix reste possible.
Lambert Consulting pose cette frontière avant d’écrire une ligne, et construit des deux côtés. Le coût réel des licences se calcule au même moment, et la question de savoir qui possède l’application une fois finie se pose dès le premier rendez-vous, pas au dernier.
Les sources Microsoft
Ce qu'un article ne peut pas savoir
Un article décrit ce qui vaut pour tout le monde. Ce qui change d'une organisation à l'autre, c'est l'inventaire : quelles applications, quels comptes, quels équipements sont réellement concernés chez vous. C'est l'inventaire qui décide de l'effort, et il ne se répond pas sur une page.
Vous parlez aux ingénieurs qui feraient le travail, pas à un intermédiaire. Réponse sous 24 heures ouvrées.
Vérifier ce qui est encore vrai
Les dates annoncées sont parfois repoussées, les produits changent de nom, les conditions évoluent. Le blog suit ces sujets au fil du temps : quand une règle change, un nouvel article le dit.
Chercher un sujet dans le blogDans le même dossier
Trois articles du même sujet. Le blog en compte 149, tous en accès libre.