Comment créer un outil interne : panneaux d'administration, approbations et remplacement des tableurs

Pour créer un outil interne, choisissez un flux aujourd'hui pénible, généralement un tableur partagé, un fil de courriels ou un canal de discussion qui fait le travail d'une base de données, et transformez-le en petite appli avec un formulaire soigné, une liste avec statuts, les bonnes permissions pour chaque rôle et un historique de qui a modifié quoi. Un générateur d'appli par IA peut produire une première version fonctionnelle en un après-midi. Ce qui fait réussir le projet, c'est de limiter le périmètre à un seul flux et de le construire avec les personnes qui s'en serviront chaque jour.

Ce qui compte comme outil interne

Les outils internes sont ces logiciels peu glamour qui font tourner une entreprise. Types courants :

Pour d'autres idées de départ, voir idées d'outils internes pour les équipes.

Faut-il vraiment le construire ?

Gardez le tableur si une seule personne le maintient, que les données sont peu nombreuses et qu'une erreur coûte peu. Construisez un outil lorsque vous constatez ces signes :

• Les gens écrasent les modifications des autres, ou personne ne sait quelle copie est la bonne
• Vous devez limiter à certaines personnes la consultation ou la modification d'une partie des données
• Vous avez rédigé une page entière d'instructions pour utiliser le tableur
• Les changements de statut doivent prévenir quelqu'un, et ces alertes sont sans cesse manquées
• Vous avez besoin d'une piste d'audit : qui a approuvé ceci, et quand

Il existe aussi une option intermédiaire. Les plateformes d'outils internes low-code (Retool, les interfaces Airtable, Softr et d'autres) offrent des briques prêtes à l'emploi au-dessus de vos données. Elles conviennent lorsque vos données sont déjà dans une base ou un tableur pris en charge et que vous voulez des écrans en glisser-déposer. Une appli construite par IA convient mieux lorsque le flux est spécifique, que vous voulez qu'elle se comporte et ait l'apparence exacte dont votre équipe a besoin, ou que vous voulez posséder le code. Pour la question générale, voir construire ou acheter un logiciel pour une petite entreprise.

Concevoir le flux avant les écrans

Écrivez le flux comme un court récit avant de rédiger le prompt. Pour un outil de validation de notes de frais :

1. Un employé soumet une dépense : montant, catégorie, date, description, photo du reçu.
2. Son manager est notifié et approuve ou refuse avec un commentaire.
3. Les dépenses au-dessus d'un plafond nécessitent aussi l'approbation de la finance.
4. La finance marque les dépenses approuvées comme payées, par lot hebdomadaire.
5. Chacun voit l'état de ses propres dépenses ; la finance voit toutes les dépenses.

À partir de ce récit, vous obtenez :

• Données : dépenses, utilisateurs, rôles, approbations (qui, décision, commentaire, date), pièces jointes.
• Statuts : soumise → approuvée par le manager → approuvée par la finance → payée, ou refusée.
• Rôles : employé, manager, finance, administrateur.
• Règles : le seuil de montant, qui peut faire passer un élément à chaque statut.
• Écrans : formulaire de soumission, « mes dépenses », « en attente de mon approbation », tableau de toutes les dépenses pour la finance, page de détail avec historique.

Décrivez le flux de cette façon et l'IA pourra construire la bonne chose dès le premier essai.

Permissions et historique

Les outils internes contiennent souvent des données sensibles : salaires, coordonnées clients, argent. Deux règles :

1. Vérifiez les rôles côté serveur pour chaque action. Un manager ne doit pas pouvoir approuver sa propre dépense en appelant directement le point d'accès d'approbation.
2. Enregistrez l'historique. Stockez chaque changement de statut et chaque modification avec son auteur et sa date. Cela tranche la plupart des « qui a modifié ceci ? » et s'avère précieux lorsque quelque chose tourne mal.

Décidez comment les gens se connectent. La connexion avec les comptes Google ou Microsoft de votre entreprise est pratique pour les équipes qui les utilisent déjà ; l'e-mail et le mot de passe fonctionnent partout. Dans les deux cas, limitez l'inscription pour que seule votre équipe puisse entrer.

Un premier prompt qui fonctionne

Construis un outil interne d'approbation des notes de frais pour une entreprise de 25 personnes. Les employés soumettent une dépense avec montant, devise, catégorie (voyage, repas, logiciels, équipement, autre), date, description et téléchargement d'une photo de reçu. Leur manager voit une liste « En attente de mon approbation » et peut approuver ou refuser avec un commentaire. Les dépenses au-dessus de 500 dollars nécessitent aussi l'approbation d'une personne ayant le rôle Finance. La finance voit un tableau de toutes les dépenses avec des filtres par statut, personne et mois, et peut marquer les dépenses approuvées comme payées. Chaque changement de statut est enregistré avec son auteur et sa date, affiché sous forme de chronologie sur la page de la dépense. Rôles : employé, manager, finance, administrateur, vérifiés côté serveur pour chaque action. Enregistre tout dans une base de données et ajoute des données d'exemple réalistes. Interface sobre, dense et rapide : c'est un outil de travail, pas un site vitrine.

Étapes de construction

1. Le tableau principal et le formulaire pour l'enregistrement central, avec des données d'exemple réalistes pour que la recherche et les filtres soient visiblement utiles.
2. Statuts et transitions, y compris qui peut faire passer un élément à chaque état.
3. Rôles et connexion, limités à votre équipe.
4. Journal d'historique sur chaque enregistrement.
5. Notifications : un e-mail ou un message de discussion lorsqu'une action est requise de la part de quelqu'un.
6. Import des données existantes depuis le tableur. Transformer un tableur en appli explique le nettoyage et l'import.
7. Test avec deux ou trois utilisateurs réels pendant une semaine avant de déployer à tous.
8. Arrêt de l'ancien processus à une date fixée. Deux systèmes en parallèle signifient qu'aucun n'est fiable.

Faire réellement utiliser l'outil

De nombreux outils internes fonctionnent parfaitement et échouent malgré tout, parce que les gens continuent à utiliser l'ancienne méthode.

• Construisez avec les utilisateurs. Observez quelqu'un accomplir la tâche aujourd'hui avant de concevoir la nouvelle version.
• Soyez plus rapide que l'ancienne méthode. Si soumettre prend plus de temps qu'envoyer un message, les gens continueront à envoyer des messages.
• Dense plutôt que joli. Les opérationnels préfèrent des tableaux avec de bons filtres et des formulaires utilisables au clavier plutôt que de grandes cartes et des espaces vides.
• Mettez en premier l'action suivante. « En attente de moi » doit être la première chose que les gens voient.

Erreurs courantes

• Reconstruire tout le tableur. Déplacez le flux pénible seul ; laissez le reste dans le tableur pour l'instant.
• Pas de responsable. Quelqu'un doit être responsable des changements et des corrections après le lancement.
• Permissions après coup. Ajouter des rôles à un outil terminé est plus difficile que de partir avec eux.
• Oublier la piste d'audit, puis en avoir besoin la première fois que de l'argent disparaît.
• Publier sur une URL publique sans connexion. Tout ce qui est interne doit exiger une connexion.

Continuer à le faire fonctionner après le lancement

Un processus change tous les quelques mois : une nouvelle étape d'approbation, une nouvelle catégorie, une nouvelle équipe. Prévoyez-le dès le départ :

• Gardez les paramètres dans des tables, pas dans le code. Les catégories, seuils et affectations d'approbateurs stockés dans la base peuvent être modifiés par un administrateur sans reconstruction.
• Rassemblez les demandes en un seul endroit. Un simple lien « proposer une modification » dans l'outil vaut mieux que des demandes dispersées dans des discussions.
• Exportez régulièrement. Un export CSV des tables principales garantit que les données ne sont jamais piégées et facilite les rapports de fin de mois.
• Testez après chaque changement. Refaites le parcours soumettre, approuver et refuser après toute modification du flux, car les bugs de permission apparaissent souvent à cet endroit.

Coûts d'exploitation

Un outil interne construit avec l'IA coûte l'hébergement, une base de données, le stockage de fichiers si les gens téléchargent des documents, et éventuellement un service d'e-mail ou de messagerie pour les notifications. Il n'y a généralement pas de licence par siège pour un outil que vous possédez, ce qui compte lorsque de nombreux utilisateurs occasionnels ont besoin d'accès. Le coût continu, c'est le temps de quelqu'un pour le maintenir.

Le construire avec Mythex

Les outils internes conviennent bien à Mythex. Vous décrivez le flux, l'agent le construit dans un aperçu en direct, ajoute une base Postgres pour les enregistrements et un stockage de fichiers pour les téléchargements, comme les reçus. Les cas d'usage outil interne et panneau d'administration de la documentation proposent des prompts de départ. Vos collègues peuvent aider à le construire dans votre espace de travail, sans frais par siège.

Deux points à connaître. Les connexions de votre équipe qui utilise l'outil font partie de l'appli que vous construisez, avec une approche que vous choisissez ; elles sont distinctes des comptes Mythex. Et Mythex n'inclut pas d'intégrations intégrées avec Salesforce, HubSpot ou Slack pour l'appli elle-même : celles-ci se connectent via leurs API avec vos propres clés. Pour un prompt de départ, essayez les modèles suivi des approbations ou outil d'administration interne, et voyez comment créer un tableau de bord si ce dont vous avez besoin, ce sont surtout des graphiques.

Questions