L’intelligence artificielle est souvent présentée comme un outil capable de faire gagner du temps. Nous avons voulu aller plus loin : l’utiliser, notamment avec ChatGPT, pour remplacer notre CRM interne par une solution développée sur mesure. L’objectif n’était pas de réaliser une démonstration technologique, mais de construire un outil réellement adapté à nos usages et de mesurer, dans un cas concret, ce que l’IA change dans la façon de concevoir un logiciel d’entreprise. Cette expérience nous a surtout permis de confronter les promesses de l’IA à la réalité d’un projet : comprendre un besoin métier, reprendre des données existantes, développer rapidement, tester, corriger, écouter les utilisateurs et éviter les régressions.
Pourquoi remplacer un CRM existant ?
Le point de départ était assez classique : nous utilisions un CRM du marché. L’outil était complet, mais une partie de ses fonctionnalités ne correspondait pas exactement à notre manière de travailler. Certaines fonctions étaient utiles, d’autres beaucoup moins, et plusieurs processus demandaient des adaptations. La question est progressivement devenue simple : plutôt que d’adapter durablement notre organisation au logiciel, pouvions-nous construire un logiciel adapté à notre organisation ? Il y a encore quelques années, cette question aurait probablement conduit à un projet long, coûteux et nécessitant une équipe de développement importante. L’arrivée des outils d’intelligence artificielle change cette équation. Ils rendent beaucoup plus accessible la conception d’un outil métier spécifique, à condition de conserver une vraie maîtrise du projet.
Ce que nous avons réellement développé
L’objectif n’était pas de reproduire notre ancien CRM à l’identique. Nous sommes repartis du besoin. La nouvelle solution couvre notamment la gestion des candidats, les besoins commerciaux, les clients et contacts, les positionnements, le recrutement, les actions commerciales, les historiques, les droits et profils utilisateurs, le reporting, différentes automatisations et les interactions avec nos outils internes. L’IA nous a permis d’accélérer de nombreuses étapes : structurer une fonctionnalité, générer du code, analyser une erreur, identifier une zone à modifier, préparer des tests ou proposer une correction. Le délai entre une demande métier et sa traduction dans l’application peut devenir extrêmement court. C’est probablement l’un des changements les plus importants : la distance entre le besoin et le logiciel se réduit fortement.
Premier enseignement : être extrêmement précis
La qualité du résultat dépend directement de la qualité de la demande. Une requête vague peut produire une réponse techniquement cohérente, mais fonctionnellement éloignée du besoin réel. Il faut donc préciser le comportement actuel, le comportement attendu, les utilisateurs concernés, les règles métier, les cas particuliers, les données concernées et surtout ce qui ne doit pas changer. L’IA peut aller très vite. Mais si elle part dans la mauvaise direction, elle peut également aller très vite dans la mauvaise direction. Le travail de formalisation du besoin reste donc essentiel. L’IA ne supprime pas la nécessité de réfléchir au fonctionnement attendu ; elle rend simplement l’exécution beaucoup plus rapide une fois le besoin correctement défini.
Le temps gagné doit être réinvesti dans le contrôle
Le développement assisté par IA accélère fortement la production, mais le temps gagné ne doit surtout pas faire disparaître la recette. Une modification apparemment simple peut provoquer une régression ailleurs dans l’application : formulaire, règle de gestion, droits utilisateurs, relation entre plusieurs données, reporting ou autre parcours utilisateur. Plus les évolutions s’enchaînent rapidement, plus le contrôle devient important. Le risque est paradoxal : parce que l’on peut modifier très vite un logiciel, on peut également accumuler très vite plusieurs modifications dont les interactions n’ont pas été suffisamment vérifiées.
Les tests ne doivent jamais devenir la variable d’ajustement
L’un des pièges du développement assisté par IA est de confondre vitesse de production et fiabilité du résultat. Parce qu’une évolution peut être développée très rapidement, on peut être tenté de réduire le temps consacré aux tests. C’est précisément l’inverse qu’il faut faire. Les tests doivent intervenir à plusieurs niveaux : tests unitaires, tests d’intégration, tests de parcours, contrôle des régressions, vérification des comportements attendus après déploiement et contrôle de l’affichage sur différents navigateurs ou formats d’écran. L’IA peut elle-même contribuer à cette démarche : générer des scénarios de tests, identifier les zones potentiellement impactées par une modification et rechercher des incohérences. Elle peut également être utilisée comme un véritable moteur de QA, capable d’exécuter des parcours fonctionnels, vérifier le comportement d’une application et comparer le résultat obtenu avec celui attendu. Mais cela ne remplace pas la validation humaine. Un logiciel peut être techniquement conforme et rester inadapté au besoin réel. Le bon modèle n’est donc pas IA ou utilisateur, mais IA + automatisation + utilisateur : l’IA augmente la capacité de contrôle, les tests automatisés sécurisent les évolutions et l’utilisateur valide la pertinence métier.
La reprise de données : l’exercice le plus rigoureux
La reprise des données de l’ancien CRM a été l’un des sujets les plus sensibles. Deux logiciels ne décrivent pas nécessairement un candidat, un besoin, un client, un statut ou un historique de la même manière. Il faut donc construire une véritable matrice de correspondance : champ source, champ cible, règles de transformation, conversion des statuts, données à conserver, données obsolètes, doublons, relations entre objets, historiques et informations manquantes. Le risque le plus difficile à détecter n’est pas qu’un import échoue, mais qu’il réussisse techniquement tout en produisant une donnée métier incorrecte. Une date mal interprétée, un statut mal converti ou une relation perdue peut être beaucoup plus problématique qu’une erreur technique immédiatement visible.
Nous avons aussi testé l’analyse automatique des remontées utilisateurs
Une autre expérimentation a consisté à laisser l’IA analyser automatiquement les demandes et anomalies remontées par les utilisateurs. Lorsque la demande est précise, l’approche est très efficace : l’IA peut comprendre le problème, identifier le code concerné, rechercher les dépendances, proposer une modification et préparer les tests associés. Mais les remontées réelles sont rarement rédigées comme des spécifications fonctionnelles. Un message comme « Je ne peux pas modifier le besoin » peut vouloir dire plusieurs choses : le bouton ne fonctionne pas, le formulaire ne s’ouvre pas, un champ est bloqué, l’enregistrement échoue, un droit manque ou le fonctionnement attendu n’est simplement pas celui qui a été développé. Ces situations sont très différentes techniquement.
Le vrai risque : l’interprétation
Lorsqu’une information manque, l’IA cherche naturellement à compléter le contexte. Cette interprétation peut être parfaitement logique sans être correcte. Une IA laissée en autonomie peut alors partir d’une mauvaise hypothèse, construire une analyse cohérente autour de cette hypothèse, identifier une solution technique, appliquer une modification et produire finalement un résultat éloigné du besoin réel. Le problème n’est donc pas toujours sa capacité à développer. Il peut être tout simplement la qualité du besoin qu’on lui demande de traiter. Cela rejoint une règle classique de l’informatique : automatiser une mauvaise compréhension ne la transforme pas en bonne décision.
Une IA autonome doit savoir quand ne pas agir
L’autonomie utile ne consiste pas uniquement à savoir agir sans intervention humaine. Elle consiste aussi à savoir identifier l’incertitude. Lorsque le comportement observé, le comportement attendu ou le contexte fonctionnel ne sont pas suffisamment clairs, la meilleure décision peut être de ne rien modifier et de demander une précision. C’est un point essentiel lorsque l’on commence à automatiser des chaînes complètes : analyser, développer, tester, déployer. Plus on donne d’autonomie à une IA, plus sa capacité à reconnaître qu’elle ne dispose pas d’assez d’informations devient importante. Une IA performante ne doit pas seulement savoir agir ; elle doit également savoir dire qu’elle n’a pas suffisamment d’éléments pour modifier le logiciel sans risque.
Ce que cette expérience change dans l’équation acheter ou développer
Cette expérience montre que l’IA ne transforme pas uniquement la manière d’utiliser les logiciels. Elle transforme aussi la manière dont on peut les construire. Pour certains besoins spécifiques, développer un outil interne devient beaucoup plus accessible qu’auparavant. Cela ne signifie évidemment pas qu’il faut remplacer tous les logiciels SaaS par des développements internes. Un logiciel du marché présente de nombreux avantages : maintenance mutualisée, évolutions continues, support, standardisation, sécurité et écosystème. Mais l’équation économique change. Une entreprise peut désormais comparer différemment le coût d’abonnement, l’adéquation réelle au besoin, la capacité d’évolution, la maîtrise des processus, la maintenance, la sécurité, la maîtrise des données et le coût d’un développement spécifique.
L’impact dépasse largement le développement logiciel
La même logique se retrouve dans de nombreux métiers. L’intelligence artificielle peut accélérer la recherche d’informations, la rédaction, l’analyse de données, le reporting, la documentation, la préparation de réunions, l’analyse de demandes et certaines tâches administratives répétitives. L’IA transforme d’abord les tâches avant de transformer les métiers. Le gain réellement intéressant n’est pas simplement de produire davantage. Il consiste à réduire le temps consacré aux tâches à faible valeur ajoutée afin de redonner du temps au jugement, à l’expertise, au dialogue et à la décision.
Conclusion : migrer une solution ne se prépare pas comme créer un nouvel outil
C’est probablement l’un des enseignements les plus importants de cette expérience. Un projet de migration n’est pas un projet de création à partir de zéro. Lorsqu’on développe une nouvelle application sans existant, il est possible de repenser immédiatement les processus, l’ergonomie et les fonctionnalités. Lorsqu’on remplace une solution utilisée quotidiennement, la priorité est différente : il faut d’abord assurer la continuité. Vouloir dans une même étape reprendre les données, reproduire les fonctions indispensables, modifier les processus, changer les règles métier, revoir l’ergonomie et ajouter de nouvelles fonctionnalités augmente considérablement le risque. Il devient ensuite difficile de savoir si un problème vient de la migration, d’une donnée mal reprise, d’un changement fonctionnel, d’une nouvelle règle ou d’une régression. La stratégie la plus robuste est donc de distinguer clairement deux étapes : d’abord reprendre correctement les données, usages essentiels, règles métier, droits, historiques et parcours indispensables ; ensuite améliorer, automatiser, simplifier les parcours, faire évoluer l’ergonomie et ajouter de nouvelles fonctionnalités.
Un bon projet reste avant tout un projet bien préparé
Séparer reprise et amélioration peut donner l’impression de ralentir le projet. En réalité, cette approche permet souvent d’aller plus vite, parce qu’elle facilite énormément l’analyse des problèmes, les tests et la validation des utilisateurs. Que l’on construise une nouvelle solution ou que l’on remplace un logiciel existant, la technologie ne suffit pas. Il faut préparer le périmètre, les données, les règles métier, les responsabilités, les étapes, les critères de validation, la stratégie de migration, la stratégie de tests et le dispositif de recette. L’intelligence artificielle peut considérablement accélérer l’exécution. Mais plus elle permet d’aller vite, plus il devient important de savoir où l’on veut aller et dans quel ordre. L’IA permet d’accélérer un projet bien préparé. Elle permet également d’accélérer un projet mal préparé. La différence reste dans la qualité de la préparation, la compréhension du métier et la capacité à contrôler ce que l’on construit.
À retenir
L’IA peut rendre crédible la construction d’un outil métier sur mesure et accélérer fortement les évolutions. Mais la précision des demandes, la qualité des données, la maîtrise des régressions, la stratégie de tests et la séparation entre reprise et amélioration restent déterminantes. Un bon projet commence toujours par une préparation claire.