À retenir sur l’internalisation du développement logiciel
- Le vibe coding rend le développement logiciel accessible à tous les profils, y compris non techniques.
- Développer en interne (équipe IT dédiée ou vibe coding) fait hériter des obligations qu’un éditeur externe portait jusqu’ici.
- Sans traçabilité formalisée, les données produites par un logiciel maison sont juridiquement contestables.
- Pour les logiciels à valeur réglementaire, le recours à un PSCo qualifié n’est pas une option.
Les risques de l’internalisation logicielle
Tous les logiciels ne présentent pas la même sensibilité. Ceux qui traitent des données réglementées, produisent des documents opposables ou s’inscrivent dans des processus audités exposent l’entreprise à des risques que l’éditeur externe aurait portés à sa place.
Risques techniques
Un logiciel développé sans méthodologie structurée accumule silencieusement une dette technique. Le code peut devenir instable. Mais le risque le plus sous-estimé est ailleurs : en l’absence de documentation du code lui-même, personne ne comprend comment il a été construit, quelles dépendances il mobilise, ni quelles décisions techniques ont été prises. Le maintenir ou le faire évoluer devient alors difficile, voire impossible.
Par exemple, un commercial développe via vibe coding un outil de suivi des commandes. Dix-huit mois plus tard, une mise à jour du système d’exploitation crée une incompatibilité. Personne dans l’entreprise ne maîtrise suffisamment le code et ne sait comment il a été construit pour intervenir.
Risques cyber
Un éditeur SaaS maintient une veille sécurité dédiée et publie des correctifs réguliers. Une équipe IT interne dispose rarement de moyens comparables. Le risque est d’autant plus élevé lorsque le code a été généré par une IA sans revue de sécurité : selon le GenAI Code Security Report de Veracode, 45 % des tâches de génération de code confiées à des LLM introduisent une vulnérabilité figurant dans le Top 10 de l’OWASP, dont des injections SQL, des mots de passe codés en dur ou des clés API exposées.
L’absence de gouvernance du code produit est le vrai risque : un code non vérifié est un code non sécurisé, quelle que soit sa qualité apparente.
Risques juridiques et probatoires
Un logiciel maison peut produire des données dont l’entreprise doit pouvoir démontrer la fiabilité face à un juge lorsqu’il traite des sujets sensibles soumis à une forte régulation. Un outil de signature électronique « maison », un module de gestion contractuelle ou un système d’archivage de documents réglementés entrent dans cette catégorie.
C’est le cas également lorsqu’une entreprise déploie un outil de time tracking RH développé en interne. Un litige prud’homal survient deux ans plus tard. La partie adverse n’a pas besoin de prouver que les données ont été modifiées : il lui suffit de démontrer qu’elles auraient pu l’être. En l’absence de traçabilité formalisée, l’entreprise ne peut pas en établir l’intégrité.
Risques de conformité (RGPD, IA Act)
Tout logiciel développé en interne qui traite des données personnelles doit respecter le RGPD dès sa conception. Le principe de privacy by design impose d’intégrer la protection des données dans les choix techniques initiaux, et non après coup. Un éditeur SaaS a généralement déjà intégré ces contraintes dans son produit. Ce n’est pas automatiquement le cas d’un outil maison qui peut ainsi se retrouver sans aucune preuve horodatée des opt-in en cas de contrôle CNIL.
L’IA Act introduit une contrainte supplémentaire pour les systèmes d’IA intégrés dans les processus internes. Certains outils développés en vibe coding, notamment ceux qui participent à des décisions RH ou commerciales, peuvent relever de la catégorie des systèmes à haut risque. L’entreprise qui les déploie sans le savoir ne dispose d’aucune documentation de conformité au moment où elle en aurait besoin.
Risques liés à la propriété intellectuelle
La titularité du code développé en interne n’est pas automatiquement acquise. Lorsque le code est produit par un salarié dans le cadre de ses fonctions, les droits patrimoniaux reviennent à l’employeur, sous réserve que les conditions de l’article L. 113-9 du Code de la propriété intellectuelle soient réunies. Lorsque le code est généré par une IA, la question n’est pas tranchée : aucune règle légale n’attribue explicitement la titularité à l’entreprise qui a prompté.
Le développement assisté par IA introduit un risque supplémentaire. Les modèles peuvent générer du code similaire à des bibliothèques sous licence propriétaire ou copyleft sans que l’entreprise en ait conscience. Par exemple, une entreprise développe via vibe coding un logiciel métier qu’elle souhaite commercialiser. Elle découvre que le code généré incorpore des extraits sous licence GPL. Elle doit soit publier l’intégralité de son code source, soit refondre le logiciel.
Impact financier
Le coût réel d’un développement interne est souvent sous-estimé au moment de la décision. Les salaires des développeurs, la maintenance corrective, les évolutions fonctionnelles et les corrections de bugs s’accumulent dans la durée. Et dans le cas du vibe coding, le coût des tokens augmente avec la complexité et la durée du projet.
Gouvernance et traçabilité : ce que le développement interne exige
Face à ces risques, trois piliers doivent structurer l’approche de l’entreprise.
Traçabilité des développements assistés par IA
Lorsque le code est généré par une IA, une question s’ajoute à celles du développement classique : qui a prompté quoi, quand et sur quelle version du code ? Sans traçabilité de prompts IA, il est impossible de distinguer ce qui relève d’une décision humaine de ce que l’IA a produit. Les conséquences sont directes sur la responsabilité juridique et sur la titularité du code.
Horodatage et valeur probante
Un dépôt Git retrace les modifications apportées au code. Il ne certifie ni la date de ces modifications, ni leur auteur, ni leur intégrité au sens juridique du terme. Un commit peut être antidaté. Un auteur peut être usurpé.
L’horodatage qualifié au sens du règlement eIDAS répond à cette limite. Il ancre chaque état du projet dans le temps de façon opposable à des tiers, avec une présomption d’exactitude qu’aucun outil interne ne peut conférer. Pour les logiciels à valeur réglementaire, cette couche de confiance ne s’improvise pas en fin de projet mais se construit tout au long du développement.
Le cas d’une entreprise qui doit faire face à un litige lié à un outil de gestion des contrats clients en est l’illustration. Elle doit démontrer qu’une version spécifique du contrat était bien celle en vigueur à une date donnée et qu’elle n’a pas été modifiée a posteriori. Sans horodatage qualifié des versions, elle ne dispose d’aucun élément opposable pour l’établir.
Recours à un PSCo qualifié
Pour les logiciels réglementés (signature électronique, archivage à valeur probante), se passer d’un PSCo qualifié a une conséquence directe : en cas de litige ou de contrôle, la charge de la preuve repose entièrement sur l’entreprise, sans qu’elle dispose des outils pour y répondre.
Des solutions comme Evidency permettent d’intégrer cette couche de confiance directement dans le workflow de développement, via API. L’autonomie que le développement interne procure n’est pas remise en cause. Mais la traçabilité et la valeur probante du logiciel produit sont renforcées.
L’internalisation logicielle renforce le besoin de s’appuyer sur un tiers de confiance
L’internalisation logicielle répond à des besoins réels. Elle offre autonomie, réactivité et maîtrise du code produit. Mais plus l’entreprise développe en interne, plus elle a besoin de s’appuyer sur des tiers de confiance qualifiés pour les logiciels qui engagent sa responsabilité juridique. Pour ceux qui traitent des données réglementées, produisent des actes juridiques ou s’inscrivent dans des processus auditables, la traçabilité opposable et le recours à un PSCo qualifié ne sont pas des précautions supplémentaires. Ils constituent la garantie indispensable pour pérenniser l’autonomie logicielle de l’entreprise sans fragiliser sa sécurité juridique.
Clause de non-responsabilité
Les opinions, présentations, chiffres et estimations présentés sur le site Web, y compris dans le blog, sont uniquement destinés à des fins d’information et ne doivent pas être considérés comme des conseils juridiques. Pour obtenir un avis juridique, vous devez contacter un professionnel du droit dans votre juridiction.
L’utilisation du contenu de ce site Web, y compris du blog, à des fins commerciales, y compris la revente, est interdite, sauf autorisation préalable de Evidency. La demande d’autorisation doit préciser le but et l’étendue de la reproduction. À des fins non commerciales, tout le matériel de cette publication peut être cité ou réimprimé librement, mais une reconnaissance est requise, ainsi qu’un lien vers ce site Web.
