Avec l’essor de l’IA générative, une nouvelle forme de développement émerge dans les entreprises : le « vibe coding ». Derrière cette promesse d’autonomie et de productivité, les risques de Shadow IT s’intensifient. Benoît-Marie Flach, fondateur de Ksaar, décrypte les transformations en cours et appelle à un repositionnement profond des DSI.
SNC : Aujourd’hui, avec l’IA générative, on voit émerger une nouvelle manière de développer, y compris chez des profils non techniques. Comment analysez-vous cette évolution ?
Benoît-Marie Flach : Aujourd’hui, directement, les métiers, avec des outils de création logiciel, sont capables de s’en servir pour développer leurs propres outils. C’est ce qu’on appelle le no-code.
De mon point de vue, on s’est rendu compte que les métiers n’avaient pas la capacité d’abstraction nécessaire pour faire des systèmes complexes, notamment sur les bases de données relationnelles. Les données restaient au niveau local et ne remontaient pas dans l’organisation, ce qui était dommage.
On a donc changé notre fusil d’épaule. Et la piste principale a consisté à accompagner les DSI, parce que c’est leur responsabilité. On a découpé l’entreprise en termes de responsabilité, et la DSI est responsable de la création logiciel. L’idée, c’était aussi que ce soit le même cerveau qui prenne le besoin, qui développe. Parce que ce qui est le plus long dans un projet informatique, côté DSI, c’est la transmission de l’individu à l’autre.
On parle depuis longtemps de shadow IT. En quoi l’IA générative change-t-elle réellement la donne ?
B.-M. F. : Dans ma tête, il y a deux visions. Une casquette que je préfère, qui est pédagogique. C’est la raison pour laquelle j’ai créé la fresque du shadow IT. Expliquer pourquoi il ne faut pas mettre ses données n’importe où, qu’est-ce que ça peut faire de mettre ces données n’importe où, c’est quoi une donnée sensible, pourquoi quand on met plusieurs données ensemble ça devient des données sensibles parce qu’on peut les croiser…
Souvent, c’est quelqu’un qui va dans son coin faire un truc, puis le mettre entre les mains des autres. Tout le monde va dire que c’est super. Et après, c’est impossible de revenir en arrière, parce que ça ne va pas passer les règles de conformité et de sécurité. Quand il n’y a pas de prise de conscience de la part du métier — de ce que c’est, et de ce que ça implique d’un point de vue sécurité de la donnée et éthique de la donnée — on va assister à des scènes pas très rigolotes.
Qu’est-ce qui devient le plus difficile à contrôler aujourd’hui pour les DSI ?
B.-M. F. : À partir du moment où c’est assumé, tout l’enjeu, c’est de savoir quelle règle on met dans la société. On peut très bien se dire : pour faire un petit test tout seul sur des données non sensibles, pour mettre son idée au clair avant de le faire développer par la DSI, pourquoi pas.
Mais le pendant, c’est qu’elle soit outillée pour aller aussi vite que la musique.
Et ensuite, comment on fait pour que la DSI aille suffisamment vite pour que ce soit acceptable pour les métiers ? Sinon, on a des outils créés par un individu, et quand il change de service, plus personne ne peut le maintenir. On ne sait plus où sont les données et on galère beaucoup plus. Ça génère des tensions énormes, parfois de la perte de chiffre d’affaires.
C’est une nécessité que la DSI soit encore plus mise en avant dans les décisions et dans le quotidien.
Quels sont les principaux risques liés à cette démocratisation du développement ?
B.-M. F. : Sur la dépendance, la sécurité et la propreté du code, aujourd’hui, c’est complètement aléatoire. Entre les mains de développeurs aguerris, ça ne pose pas trop de problèmes, parce qu’ils connaissent les règles du développement. Mais si on le met dans les mains de novices, il va avoir un véhicule qu’il ne sait pas conduire. Il a l’impression de savoir conduire parce qu’il a réussi à accélérer un peu, et ça impressionne tout le monde — mais ce n’est pas maîtrisé.
Le cœur du problème, c’est qu’on met un outil entre les mains de quelqu’un qui ne sait pas conduire.
Si on a des connaissances en amont, on est capable de maîtriser. Si on n’a pas fait l’effort d’avoir les connaissances, on s’en sert pour paraître plus grand qu’on est.
Historiquement, les DSI ont souvent cherché à interdire le shadow IT. Ce modèle est-il encore viable ?
B.-M. F. : Il y a un modèle à changer. La DSI doit faire de la pédagogie, et être suffisamment bien outillée pour aller vite. On doit passer d’un modèle où elle empêche, à un modèle où on a envie de passer du temps avec elle. Quand j’ai une idée, je dois avoir une oreille attentive. On va itérer ensemble, produire la meilleure chose possible.
Si on dit juste non et qu’on n’explique pas pourquoi, on va avoir plein de choses complètement cachées.
Vous défendez une approche basée sur des plateformes no-code encadrées et souveraines. En quoi est-ce une réponse ?
B.-M. F. : On redonne à la DSI une capacité à délivrer beaucoup de logiciels rapidement, tout en ayant de la donnée centralisée. On intègre la conformité, la sécurité et la souveraineté. On donne une sorte de petit château fort qui fonctionne bien. À l’intérieur, on peut créer beaucoup d’applications. On ne génère pas de code : on génère des fichiers de configuration qui ne peuvent pas être inventés. Et on peut permettre à un développeur interne de venir rajouter des modules personnalisés.
Est-ce que cela ne risque pas malgré tout d’amplifier le shadow IT ?
B.-M. F. : Si c’était directement dans les mains des métiers, oui. Mais comme c’est au niveau de la DSI, ça permet de rassembler plusieurs métiers et de structurer. Et surtout de se poser la question en amont : est-ce que je prends un outil qui existe déjà, est-ce que je développe. À partir du moment où ça reste à la DSI, on garde le contrôle.
À quoi ressemblera une entreprise où le « vibe coding » est pleinement installé ?
B.-M. F. : D’abord, on explique. On fait beaucoup de pédagogie. On fait une vraie transition réfléchie, pas une fuite en avant. Ensuite, on met des règles. Puis un dispositif qui permet d’accompagner les métiers et d’aller très rapidement.
Si les métiers sont satisfaits, ils n’ont pas besoin de créer des logiciels par eux-mêmes. Sinon, on peut autoriser à créer un logiciel, mais avec un lien fort avec la DSI. On peut donner l’autorisation de créer un logiciel sur la plateforme, mais il ne peut pas être mis en production sans validation de la DSI. C’est d’abord de la pédagogie, puis de l’accompagnement, et enfin de l’autonomie contrôlée.
