Depuis l’arrivée d’outils comme Lovable, Replit ou Cursor, la promesse d’aller vite pour créer un outil de gestion interne attire de plus en plus de dirigeants. Mais la vitesse à laquelle une IA génère du code n’est jamais le vrai sujet. Ce qui détermine la réussite d’un ERP ou d’un CRM construit avec l’intelligence artificielle, c’est la méthode suivie avant même d’écrire le premier prompt.
Ces outils ne se limitent pas aux plateformes no-code. Des solutions comme Claude Code, Codex ou Cursor permettent à des profils plus techniques de piloter un agent d’intelligence artificielle directement depuis un terminal ou un éditeur de code, avec un contrôle plus fin sur l’architecture, les dépendances et la qualité du code généré. Qu’il s’agisse d’un outil no-code ou d’un agent de développement piloté en ligne de commande, la méthode reste la même : elle précède toujours l’écriture du premier prompt.
Clarifier le besoin avant de choisir un outil
Beaucoup de projets démarrent par la mauvaise question : quel outil utiliser, plutôt que quel problème résoudre. Un CRM qui doit simplement suivre des rendez-vous n’a pas la même structure qu’un outil qui doit croiser des dossiers clients, des types de contrats et des intervenants répartis sur tout un territoire. Cette étape correspond au cadrage fonctionnel : lister les objets métier à gérer, les règles de gestion qui s’appliquent à chacun, et les utilisateurs qui vont s’en servir au quotidien avec des droits différents selon leur rôle.
Voici un exemple de prompt possible :
Je veux créer une application de gestion de dossiers pour une société qui coordonne des experts sur tout le territoire. Les objets principaux sont : Client, Dossier, Rendez-vous, Expert, Type de sinistre. Chaque dossier est lié à un client, à un type de sinistre, à un expert assigné selon sa zone géographique, et à un historique de rendez-vous. Un dossier ne peut pas être clôturé si les pièces justificatives ne sont pas toutes chargées. Propose-moi la liste des champs pour chaque objet avant de générer quoi que ce soit.
Cartographier les flux existants
Une fois le besoin posé, il faut regarder comment l’entreprise fonctionne réellement aujourd’hui, souvent avec des fichiers Excel, des échanges par mail ou plusieurs outils qui ne communiquent pas entre eux. Cette cartographie fait apparaître les doublons de saisie, les moments où l’information se perd, et la nécessité d’avoir une source de vérité unique pour chaque donnée plutôt que trois versions différentes du même dossier client.
Voici un exemple de prompt possible :
À partir de cette liste de champs : nom du client, numéro de dossier, type de sinistre, statut du dossier, expert assigné, zone géographique, date du rendez-vous, pièces jointes, génère un schéma de base de données relationnelle avec les tables, les clés primaires et les clés étrangères nécessaires. Explique les choix de normalisation avant d’écrire le code.
Choisir l’approche selon la complexité réelle du projet
Toutes les entreprises n’ont pas besoin du même niveau d’outillage. Un besoin simple, avec peu d’utilisateurs et des règles claires, peut être couvert par une approche no-code ou low-code, construite rapidement et ajustée au fil des retours terrain. Un besoin plus complexe, avec plusieurs métiers, une volumétrie importante ou des règles de sécurité strictes, demande un développement encadré par un profil technique capable d’éviter la dette technique et de penser la scalabilité dès le départ.
Voici un exemple de prompt possible :
Mon volume prévu est de 500 dossiers actifs et une cinquantaine d’utilisateurs simultanés, répartis dans toute la France. Compare pour ce cas précis une approche no-code type Supabase avec interface générée, et une approche avec base PostgreSQL et backend dédié. Indique les limites de chaque option à un an.
Sécuriser les données dès la conception
Un ERP ou un CRM manipule presque toujours des données sensibles : informations clients, contrats d’assurance, données personnelles au sens du RGPD. La sécurité ne s’ajoute pas après coup, elle se pense dès la conception, avec une gestion fine des rôles et permissions, une politique de Row Level Security pour que chaque utilisateur ne voie que les données qui le concernent, et une journalisation des accès pour tracer qui a consulté quel dossier.
Voici un exemple de prompt possible :
Un gestionnaire ne doit voir que les dossiers de sa région. Un expert ne doit voir que les dossiers qui lui sont assignés. Un administrateur voit tout. Active le Row Level Security sur toutes les tables concernées, génère les politiques correspondantes, et ajoute un log d’audit qui enregistre chaque consultation d’un dossier client avec l’identité de l’utilisateur et l’horodatage.
Cadrer la construction avant de la lancer
Dernière étape avant le développement proprement dit : formaliser un produit minimum viable, avec les écrans prioritaires, les règles de validation, et un périmètre volontairement resserré. Vouloir tout construire d’un coup est l’une des principales causes d’échec de ces projets. Une première version testée avec de vrais utilisateurs, dans un environnement de test séparé de la production, permet de corriger les erreurs avant qu’elles ne touchent de vraies données clients.
Voici un exemple de prompt possible :
Construis une première version limitée à trois écrans : la liste des dossiers avec filtres par statut et par région, la fiche dossier avec l’historique des rendez-vous, et le formulaire de création de dossier. Ne développe pas encore le module de facturation. Mets en place un environnement de test distinct de la production avant toute mise en ligne.
Construire un ERP ou un CRM avec l’aide de l’intelligence artificielle change la vitesse d’exécution, pas la nécessité de la méthode. Les entreprises qui réussissent ces projets sont celles qui cadrent le besoin, les flux et la sécurité avant de lancer la construction, et qui savent écrire des instructions précises plutôt que de laisser l’IA deviner ce dont elles ont besoin.