Power Apps
Le tableur qui pilote un processus critique a un nom : une application qui n’a jamais été écrite.Il reste toujours un processus que rien n’attrape : une validation à trois mains, un contrôle fait le vendredi, un calcul que personne d’autre ne fait comme vous. Nous en faisons un outil qui tient — les mêmes données, mais avec des rôles, un historique, une validation et un usage mobile.
Vous en avez au moins trois
Ils ne sont pas dans le budget informatique, personne ne les a demandés, et pourtant l’entreprise en dépend. Ce sont les outils que les métiers ont fabriqués eux-mêmes, faute de mieux.
Le fichier au nom de son auteur
Suivi_demandes_v7_JM.xlsx.
Deux personnes l’ouvrent, une seule version survit, et personne ne sait qui a modifié la
ligne 214.
Le jour où Jean-Marc s’en va, la règle de calcul part avec lui.
Le contrôle du vendredi
Quelqu’un extrait deux listes, les compare à la main, et corrige les écarts. Toutes les semaines, depuis six ans.
Deux heures par semaine : treize jours de travail par an, pour une vérification qu’une machine ferait mieux.
Les deux systèmes qui ne se parlent pas
La commande est saisie ici, recopiée là. Entre les deux, un fichier échangé par courriel, et une personne dont c’est devenu le métier.
Chaque ressaisie est une occasion de se tromper, et elle est prise.
Les mêmes données. Ce qui change, c’est ce qui les entoure.
Ce n’est pas un projet informatique, c’est une mise en ordre. Les colonnes ne changent pas, les règles de calcul non plus : ce qui apparaît, c’est tout ce qu’un fichier ne sait pas faire.
Suivi_demandes_v7_JM.xlsx
- —Le nom de son auteur est dans le titre du fichier
- —Deux personnes l’ouvrent, une seule version survit
- —Aucun historique : qui a changé cette ligne, et quand ?
- —Aucun droit : qui l’ouvre voit tout, y compris ce qu’il ne devrait pas
- —Le contrôle se fait à la main, tous les vendredis
- —Illisible sur un téléphone, donc jamais rempli sur le terrain
- —La règle de calcul vit dans une formule que personne ne relit
Si son auteur part, personne ne sait comment il calcule.
La même chose, mais tenue
- +Les mêmes colonnes, les mêmes règles — reprises telles quelles
- +Plusieurs personnes en même temps, sans version perdue
- +Un historique complet, daté et attribué
- +Des rôles : qui saisit, qui valide, qui ne voit rien
- +Le contrôle du vendredi se fait tout seul, le vendredi
- +S’ouvre dans Teams, et sur le téléphone du terrain
- +La règle de calcul vit à part : testable, versionnable
Si son auteur part, l’outil continue de tourner.
Quatre formes d’outils, et pas seulement des écrans
« Power Apps » désigne l’interface. Ce que nous construisons autour compte au moins autant : la base, les raccordements, les traitements, et la règle métier tenue à part.
L’application que les métiers ouvrent
Un écran par tâche, des listes qui se filtrent, une saisie qui refuse l’incohérence. Dans le navigateur, dans Teams, ou sur le téléphone de celui qui est en déplacement.
Des données qui ont enfin une forme
Sur Dataverse : des tables, des relations, des droits et un historique. C’est ce qui fait la différence entre une application d’entreprise et un formulaire joli.
Faire parler ce qui ne se parlait pas
L’ERP, le CRM, la comptabilité, un logiciel métier, un partenaire extérieur. Par connecteur quand il existe, par web service et interface programmable quand il n’existe pas.
Ce qui se fait encore à la main
Le rapprochement du vendredi, la relance à J+30, l’export mensuel, la validation qui attend dans une boîte : des traitements qui tournent seuls et qui préviennent quand ils échouent.
Le calcul que personne d’autre ne fait comme vous
Un barème, une tarification, une éligibilité, une répartition. Construit à part, testé sur vos cas réels, versionné — et appelé par tout ce qui en a besoin.
Ce qui existe déjà n’est pas perdu
Les données du fichier sont reprises, nettoyées et contrôlées. Le premier jour, l’application contient l’historique — sinon personne ne l’adopte.
Ce que nous faisons, et dans quel ordre
Le premier point est celui que l’on saute presque toujours, et c’est celui qui fait échouer les applications métier.
Le processus réel — observé, pas raconté
Nous regardons quelqu’un le faire. En une matinée, on découvre les trois exceptions que personne ne mentionne en réunion : le cas du client historique, la dérogation accordée par oral, le contournement inventé un jour de rush et devenu la règle.
Une application construite sur le processus raconté ne survit pas à sa deuxième semaine.
Le modèle de données
Les tables, leurs relations, les droits et l’historique. C’est la partie invisible et c’est celle qui décide de ce que l’application pourra devenir dans trois ans.
L’application et ses rôles
Un écran par tâche, pas un écran par table. Ce qui n’est pas utilisé tous les jours est rangé ailleurs : c’est le nombre de champs visibles qui décide de l’adoption.
Les raccordements et l’automatisation
Les autres systèmes, dans les deux sens, et les traitements qui tournent seuls. Avec la surveillance qui va avec : un traitement qui échoue en silence est pire que pas de traitement du tout.
Le maintien, et la reprise en main
Une application métier vit : le processus change, une exception nouvelle apparaît, un système en face est remplacé. Nous la faisons évoluer — et si vous voulez la reprendre en interne, nous formons vos équipes plutôt que de vous garder captifs.
Combien de temps, honnêtement
Des fourchettes, pour une première application métier de taille raisonnable.
L’hypothèse : un processus, une vingtaine d’utilisateurs, une reprise depuis un tableur, un ou deux systèmes à raccorder, et un responsable métier disponible une demi-journée par semaine. Un processus à plusieurs variantes selon les pays ou les entités allonge nettement le premier temps.
Observation
Le processus réel, ses exceptions, le périmètre de la première version.
Modèle et reprise
Tables, relations, droits, données existantes reprises et contrôlées.
Application
Écrans, rôles, essais avec les utilisateurs, corrections.
Raccordements et bascule
Les autres systèmes, les traitements, la mise en service.
Huit à quatorze semaines pour une première application en production. Une deuxième application sur le même modèle de données va nettement plus vite : le socle est posé, les droits existent, les raccordements aussi.
Ce qui est spécifique vit à part.
Hors de l’application qui l’utilise
Une règle de calcul enfouie dans un écran ne se teste pas, ne se relit pas et se duplique dès qu’un deuxième outil en a besoin. Sortie de l’application, elle sert partout et se corrige une seule fois.
Hors du système qui en consomme les résultats
La logique qui vous est propre ne doit pas vivre dans l’ERP ni dans le progiciel du voisin : le jour où l’un des deux est remplacé — et ce jour arrive — elle reste.
Donc testable, versionnable, supervisable
On peut lui passer cent cas connus et vérifier les cent réponses. On sait quelle version a produit quel résultat, et quand. Et on voit qu’elle tourne, ou qu’elle a échoué.
Une application métier faite par un utilisateur devient un risque au bout de deux ans. Elle marche, tout le monde s’en sert, et personne ne sait plus comment elle calcule : son auteur est parti, rien n’est documenté, rien n’est testé, et plus personne n’ose y toucher.
Ce qu’il faut savoir avant de signer
Cinq points, dont deux qui expliquent l’essentiel des mauvaises surprises de budget sur ce sujet.
Deux familles d’applications, et le choix se fait tôt
La première part de l’écran : on dessine l’interface, on la branche sur des données. Rapide, souple, parfaite pour un formulaire ou un usage mobile simple.
La seconde part des données : on décrit les tables, les relations et les droits, et les écrans en découlent. Plus longue à poser, incomparablement plus solide dès qu’il y a des rôles, des validations et de l’historique.
Nous tranchons au cadrage. Se tromper de famille est la première cause de reprise à zéro sur ce type de projet.
Le piège des connecteurs
Se raccorder à certains systèmes suppose une licence supérieure pour chaque utilisateur de l’application. C’est parfaitement légitime, mais cela transforme un budget quand l’application passe de vingt à deux cents personnes.
Nous le vérifions avant l’offre, pas au moment de la mise en service.
Vos applications existantes ne sont pas perdues
Si vos équipes ont déjà fabriqué des applications, la bonne réponse est rarement de tout refaire. Nous les reprenons, nous les documentons, nous les mettons aux normes de l’entreprise — et nous ne refaisons que ce qui doit l’être.
Ce qui relève d’une application, et ce qui n’en relève pas
Répondre à des questions sur des documents, c’est un agent — pas une application. Gérer des clients et des affaires, c’est un CRM du commerce, pas un développement.
Nous vous le dirons, y compris quand la réponse réduit notre part.
Le code et la documentation vous appartiennent
Modèle de données, écrans, traitements, règles métier et documentation sont livrés et restent chez vous. Si vous voulez reprendre la main en interne, nous formons vos équipes.
Un prestataire dont vous ne pouvez pas vous passer n’est pas un bon prestataire.
Ce qui se branche dessus
Une application métier n’est presque jamais seule. Voici les trois voisins qu’elle rencontre.
Dynamics 365
Vos applications sur mesure et les applications du commerce écrivent au même endroit : une seule fiche client, un seul jeu de droits, un seul historique.
La gamme Dynamics 365 La frontièreCopilot Studio
Répondre sur des documents, c’est un agent. Orchestrer un processus à sept étapes avec des validations, c’est une application. La page voisine explique où passe la ligne.
La page Copilot Studio Le reste du métierNos services
Intégration entre systèmes, web services et interfaces programmables, modernisation d’applications anciennes : le développement ne s’arrête pas à Power Apps.
Voir nos servicesMontrez-nous le fichier
Celui dont tout le monde dépend et que personne n’assume. Dites-nous ce qu’il contient, qui s’en sert et ce qui arriverait s’il disparaissait ce soir. Nous revenons avec un périmètre, une charge, un calendrier et des livrables nommés.
L’établissement de l’offre est gratuit. Les études de conception et les audits font partie du mandat. Nous sommes autorisés à la location de services depuis 2018 : un développeur Power Platform peut aussi rejoindre votre équipe pour une durée déterminée.
Que se passe-t-il si ce fichier disparaît ce soir ?
Si la réponse est « rien de grave », laissez-le où il est : tous les tableurs ne méritent pas une application, et nous serons les premiers à vous le dire.
Si la réponse est « on arrête de facturer », ou « on ne sait plus qui doit être payé », alors ce n’est plus un fichier. C’est une application qui n’a jamais été écrite, et elle mérite de l’être.