Développement assisté par IA : devez-vous laisser vos collaborateurs développer leurs propres applications avec l’IA ?

À l’ère de l’IA générative et du vibe coding, les collaborateurs conçoivent désormais leurs propres outils métier. Entre liberté d’expérimenter sur le terrain et nécessité d’encadrer la sécurité des données, comment les entreprises peuvent-elles transformer ce bricolage numérique en véritable levier de performance ?

Cette semaine, j’ai publié un épisode de podcast consacré au vibe coding, dans lequel Julien Saumande, un expert du sujet, nous expliquait cette pratique et ce qu’elle change dans le monde du développement.

Le principe : décrire à une IA ce que l’on souhaite obtenir, lui faire générer le code d’une application, puis ajuster le résultat par des échanges successifs. Cette approche facilite la création de logiciels, même si obtenir une première version qui fonctionne ne garantit pas encore sa fiabilité.

Il y a quelques mois, je vous avais également parlé du citizen development : la possibilité, pour des collaborateurs dont le développement informatique n’est pas le métier, de créer eux-mêmes des outils adaptés à leurs besoins.

Ces deux sujets se rejoignent. Avec des outils comme Claude Code ou Antigravity, un comptable, une assistante de direction ou un chef de projet peut envisager de construire une application pour simplifier une partie de son travail : préparer un reporting, suivre des demandes, éviter des ressaisies ou automatiser une tâche répétitive.

Pour un manager ou un dirigeant, cette perspective suscite forcément des questions.

• Combien de temps les collaborateurs vont-ils consacrer à ces développements ?
• Est-ce que cela risque de les éloigner de leurs missions ?
• Les outils créés amélioreront-ils réellement leur travail ?
• Comment vérifier que leurs résultats sont justes ?
• Quels risques feront-ils courir aux données de l’entreprise ?
• Qui s’en occupera en cas de problème ?
• Et, au bout du compte, combien cela coûtera-t-il et qu’y gagnera-t-on ?

Ces interrogations sont légitimes. Elles peuvent aussi conduire à vouloir tout contrôler avant même que quelqu’un ait commencé à expérimenter.

Mon avis est qu’il faut laisser une place à cette expérimentation, avec quelques limites compréhensibles dès le départ, puis davantage d’organisation lorsque les outils commencent à servir à l’entreprise.

Tout le monde n’a pas à devenir développeur

Le premier point, à mes yeux, est de ne pas transformer cette possibilité en obligation.

Certains collaborateurs auront envie de s’en emparer. D’autres manqueront de temps, d’intérêt ou d’aisance avec cette manière de travailler. Cela ne dit rien, en soi, de leur valeur professionnelle.

Une présentation, quelques démonstrations ou un atelier peuvent aider chacun à comprendre ce qui devient possible. Ensuite, laissons les volontaires essayer, sans faire de la création d’applications un nouveau critère de réussite pour tous.

Il faut aussi distinguer la possibilité de commencer et la capacité à construire un outil fiable. L’IA facilite l’écriture du code, mais il reste nécessaire de savoir expliquer son besoin, décomposer une tâche, identifier les exceptions et vérifier le résultat.

La connaissance du métier est ici un atout précieux. La personne qui réalise une opération chaque semaine sait souvent très bien où elle perd du temps. Elle peut repérer une amélioration qui n’aurait jamais fait l’objet d’un projet informatique.

Cela lui donne un bon point de départ. Elle pourra avoir besoin d’aide pour la suite.

Laisser une vraie place au bricolage

Je crois qu’une première phase assez libre est utile. Un collaborateur essaie quelque chose, constate que cela fonctionne mal, modifie son approche et découvre parfois un usage auquel personne n’avait pensé.

Tous les essais ne donneront pas une application utile. Il faut accepter cette part d’apprentissage si l’on souhaite que les gens explorent réellement.

Je ne demanderais donc pas un dossier de rentabilité avant chaque tentative. Un accord simple sur le temps disponible et les priorités à respecter me paraît suffisant au départ. Le manager peut laisser une marge d’autonomie, puis faire un point après une période convenue.

Cette liberté suppose toutefois un environnement prévu pour les essais. Concrètement, les collaborateurs doivent savoir quels outils ils peuvent utiliser, avec quelles données et jusqu’où ils peuvent aller sans solliciter quelqu’un.

Pour commencer, on peut travailler avec des données fictives, sans connexion aux logiciels critiques de l’entreprise et sans envoi automatique à des clients. Un essai raté doit pouvoir rester un essai raté, sans conséquence pour les opérations.

La DSI, le responsable informatique ou le prestataire de confiance a un rôle à jouer pour rendre ce cadre accessible. Si les règles sont incompréhensibles ou si chaque question ouvre une procédure interminable, les collaborateurs risquent de renoncer ou de poursuivre discrètement.

Enfin, donnons aux volontaires l’occasion de partager leurs découvertes. Une courte démonstration peut faire émerger d’autres usages, éviter des développements en double ou montrer les limites d’une idée. Les échecs peuvent aussi être instructifs.

Vérifier qu’une application est vraiment nécessaire

Avant de pousser une idée trop loin, une question mérite d’être posée : avons-nous réellement besoin de développer cet outil ?

La fonction recherchée existe peut-être déjà dans un logiciel de l’entreprise. Un collègue a peut-être résolu le même problème. Et il arrive que le meilleur moyen de gagner du temps soit de supprimer une étape devenue inutile.

Rendre la création d’applications plus accessible peut donner envie de tout résoudre par une nouvelle application. Un échange rapide avec les personnes concernées peut éviter de consacrer plusieurs jours à reproduire une fonction disponible ou à automatiser un processus qu’il faudrait revoir.

Repérer le moment où le bricolage devient un outil de travail

Imaginons maintenant qu’un collaborateur crée un petit outil pour préparer son reporting. Deux collègues lui demandent de l’utiliser. Quelques mois plus tard, tout le service s’appuie dessus.

C’est une réussite. C’est aussi un changement de responsabilité.

Une application utilisée régulièrement par une équipe mérite un examen plus attentif : ses résultats sont-ils fiables ? Ses accès sont-ils correctement définis ? Ses données sont-elles sauvegardées ? Quelqu’un peut-il la reprendre si son créateur s’absente ou quitte l’entreprise ?

Ce passage doit être repéré avant que l’outil devienne indispensable. L’utilisation par d’autres personnes, la connexion à des données réelles ou l’intervention dans une opération client sont de bonnes occasions de faire le point.

Le niveau de vérification doit rester proportionné à l’usage. Un outil personnel de mise en forme de texte et une application qui calcule les devis de l’entreprise n’appellent pas les mêmes précautions.

Pour un outil qui prend de l’importance, je prévoirais au minimum un responsable identifié, une courte documentation, des tests adaptés et une solution de repli en cas de panne. Un regard technique compétent peut également devenir nécessaire.

L’objectif est de permettre à une bonne idée de durer.

Vérifier les résultats, autant que la sécurité

Quand on parle des risques, on pense rapidement aux fuites de données. Il faut aussi parler des erreurs métier.

Une application peut sembler fonctionner parfaitement et appliquer une mauvaise règle de calcul. Elle peut produire un devis erroné, oublier une catégorie de clients dans un reporting ou traiter deux fois une demande.

Une interface convaincante ne suffit donc pas à valider un outil.

La personne qui connaît le métier doit vérifier ses résultats sur des situations habituelles, mais aussi sur des exceptions : une donnée manquante, une remise particulière, un doublon, une saisie incorrecte. Pour les usages importants, une seconde personne devrait participer à cette vérification.

Au début, comparer les résultats avec la méthode existante peut permettre de repérer des écarts avant de s’appuyer pleinement sur l’application.

Reconnaître le travail de ceux qui se prennent au jeu

Je pense que certaines équipes verront émerger des collaborateurs particulièrement à l’aise avec ces pratiques. Ils développeront leurs propres outils, puis aideront les autres à en créer.

Cette évolution peut être très intéressante. Elle permet de rapprocher la connaissance des besoins et la capacité à y répondre.

Il faut toutefois regarder ce qu’elle implique. Développer pour ses collègues signifie aussi répondre à leurs questions, corriger les problèmes et gérer les demandes d’évolution.

On ne peut pas durablement ajouter ces responsabilités à une mission principale déjà bien remplie sans arbitrer la charge de travail.

Si cette contribution devient régulière, il faut lui accorder du temps, la reconnaître et prévoir un relais. L’entreprise doit éviter de dépendre d’une seule personne dont le savoir-faire resterait invisible.

Évaluer la valeur créée au bon moment

La question du coût reste entière. Les abonnements aux outils d’IA ne représentent qu’une partie de la dépense : il faut aussi compter le temps de création, les tests, l’hébergement éventuel, la maintenance et l’accompagnement des utilisateurs.

Après la phase de découverte, il me paraît donc normal de demander ce que l’outil apporte.

Combien de temps fait-il gagner, et à quelle fréquence ? Combien de personnes l’utilisent réellement ? Réduit-il les erreurs ou les délais ? Rend-il une tâche moins pénible ? Combien de temps faut-il consacrer à son entretien ?

Ces questions peuvent rester simples. Il s’agit de comparer une situation avant et après, avec quelques observations concrètes.

Une heure libérée chaque semaine représente une capacité disponible supplémentaire. Sa valeur dépend ensuite de ce que l’on peut en faire. Et une expérimentation qui ne trouve pas son usage peut être arrêtée : tout projet commencé n’a pas vocation à devenir permanent.

Décider aussi à quoi servira le temps gagné

C’est une question managériale que je trouve essentielle.

Si un collaborateur pense que toute amélioration entraînera immédiatement une augmentation de sa charge de travail, quelle sera son envie de partager ses découvertes ?

Le temps gagné peut servir à mieux accompagner les clients, améliorer la qualité, absorber des pics d’activité, se former ou réduire une surcharge chronique.

L’entreprise a intérêt à rendre ces bénéfices visibles et à en discuter avec les personnes concernées. La réduction de la pénibilité constitue elle aussi un résultat utile.

La façon dont les gains sont utilisés influencera la confiance et l’envie de proposer de nouvelles améliorations.

Traiter concrètement la sécurité des données

Je ne suis pas spécialiste de la sécurité, et c’est un sujet que je souhaite approfondir avec mon ami Pascal Yim. Mais quelques questions doivent trouver une réponse dès le départ : quelles données peut-on transmettre à l’outil d’IA ? Où sont-elles conservées ? Qui peut accéder à l’application ? Qui appeler en cas d’incident ?

Le choix des fournisseurs et de l’hébergement mérite également d’être examiné, notamment pour garder la maîtrise de ses données et pouvoir changer de solution si nécessaire.

La souveraineté et la sécurité sont liées, mais elles ne se confondent pas. Un hébergement choisi avec soin ne dispense pas de vérifier les droits d’accès, les sauvegardes ou la protection des identifiants.

Les collaborateurs ont besoin de consignes concrètes et d’un interlocuteur disponible pour ces questions. Leur demander simplement de « faire attention » laisse trop de place à l’interprétation.

Donner la possibilité d’essayer, puis accompagner les usages

Je suis donc favorable à ce que les entreprises laissent leurs collaborateurs volontaires développer des outils avec l’IA. Avec de la place pour apprendre, un cadre adapté aux risques et un accompagnement lorsque les usages grandissent.

Le rôle du manager consiste à donner cette possibilité, à observer ce qu’elle produit et à prendre les décisions nécessaires lorsqu’une initiative devient utile à l’équipe. Il lui revient aussi de reconnaître les contributions et de décider, avec les collaborateurs, comment employer les gains obtenus.

Vous pourriez être surpris par les idées qui émergeront. Certaines resteront des essais. D’autres amélioreront discrètement le quotidien. Quelques-unes mériteront peut-être de devenir de véritables outils d’entreprise.