Ce que l'IA open source n'apporte pas d'office
L'open source apporte le code source, une utilisation libre et souvent une communauté active. Ne sont pas inclus d'office : la garantie, un interlocuteur en cas de panne, des mises à jour de sécurité testées pour l'ensemble, des droits de l'annuaire jusqu'aux logiciels métier, un journal inaltérable, des preuves pour la protection des données et les représentants du personnel, et la formation. Ces tâches reviennent à l'exploitant, qu'il les assure lui-même, via un prestataire ou par une plateforme achetée.
Qu’apporte l’open source ?
Beaucoup. Un logiciel sous une licence open source reconnue peut être utilisé, examiné, modifié et redistribué par tous, sans redevance de licence. De nombreux composants pour l’IA sont mûrs et largement répandus : logiciels qui exécutent des modèles sur des GPU, interfaces, bases de données, services d’authentification. Les plateformes prêtes à l’emploi s’appuient aussi sur eux ; basebox utilise par exemple vLLM et Keycloak.
Ce que l’open source n’est pas : un produit assorti d’engagements. Les licences répandues Apache 2.0 et MIT fournissent le logiciel « en l’état » et excluent la garantie et la responsabilité dans la mesure permise par la loi. Certains projets ont leurs propres licences avec des conditions, comme Open WebUI avec une clause sur le nom de marque. Il faut donc lire le fichier de licence avant tout déploiement.
Que manque-t-il, et qui le fournit ?
| Tâche | Ce que fournit le logiciel | Ce que l’exploitant ajoute |
|---|---|---|
| Garantie et responsabilité | en général exclues | risque propre ou contrat avec un prestataire |
| Mises à jour de sécurité | mises à jour par projet, à son propre rythme | suivre les avis, tester l’ensemble, installer |
| Droits | rôles et groupes dans certains composants | droits issus de l’annuaire, de bout en bout jusqu’aux logiciels métier |
| Connexion | interfaces et extensions | construire des connexions où chaque personne ne voit que ce qu’elle a le droit de voir |
| Journal | paramètres par composant | un journal que personne ne peut modifier après coup, avec une durée de conservation |
| Modèle d’IA | libre choix | tester les modèles, tester les changements, clarifier la licence du modèle |
| Protection contre la manipulation | selon le projet | contrôle des instructions cachées, droits, validation humaine |
| Preuves | aucune | AIPD, registre des activités de traitement, mesures techniques et organisationnelles, nomenclature logicielle |
| Support | communauté, sans engagement | interlocuteur, suppléance, délai de réaction |
| Formation | documentation du projet | mesures de maîtrise de l’IA selon l’art. 4 du règlement sur l’IA |
Pourquoi cela n’apparaît-il que plus tard ?
Un essai se déroule en général avec peu de personnes, des données d’exemple et un collègue motivé qui connaît tout. Les éléments manquants ne deviennent importants que lorsque de vraies données doivent entrer : la protection des données, la sécurité de l’information et les représentants du personnel posent alors des questions sur les droits, le journal et les documents. Et quand ce collègue part en congé, on voit qui d’autre sait comment tout fonctionne. À ce sujet, le guide facteur bus.
Quelles obligations restent à l’exploitant ?
- Protection des données : celui qui utilise l’IA est responsable du traitement. Il lui faut un registre des activités de traitement (art. 30 RGPD), des mesures techniques et organisationnelles appropriées (art. 32) et, pour les données sensibles, en général une analyse d’impact relative à la protection des données (art. 35). Voir AIPD pour l’IA.
- Maîtrise de l’IA : l’art. 4 du règlement sur l’IA exige des mesures pour les collaborateurs qui travaillent avec l’IA, quelle que soit l’origine du logiciel.
- Sécurité de l’information : l’IA développée en interne relève de votre propre SMSI et, en cas d’obligations NIS2, de la gestion des risques. Voir le guide ISO 27001 et NIS2 pour l’IA développée en interne.
- Responsabilité : qui construit un environnement d’IA à partir de composants open source peut être lui-même considéré comme fabricant. Voir Responsabilité : développement open source ou plateforme achetée ?
Le Cyber Resilience Act prévoit pour les gestionnaires de projets open source des obligations propres et plus légères (art. 24). Pour l’établissement qui assemble et exploite les composants, cela ne change rien à ses propres tâches.
Quand le développement interne reste-t-il le bon choix ?
Lorsqu’une équipe assume durablement les tâches du tableau, par exemple dans la recherche ou dans un centre de données doté de sa propre équipe plateforme. Lorsque des exigences très particulières ne sont couvertes par aucun produit existant. Ou lorsque l’IA ne sert qu’à quelques spécialistes qui n’ont pas besoin de connexion aux logiciels métier. Le guide comparatif du coût total (TCO) compare les coûts des deux voies.
Comment cela fonctionne-t-il avec basebox ?
basebox apporte les éléments du tableau : droits issus de votre annuaire, connecteurs avec le propre accès de chaque personne, un journal d’audit inaltérable, mises à jour et support compris dans la licence, accord de traitement des données, mesures techniques et organisationnelles et accord selon le § 203 StGB (Code pénal allemand, secret professionnel) à télécharger. Les clients voient la nomenclature logicielle (SBOM) dans leur basebox ; avant l’achat, nous l’envoyons sur demande. Les formations réservées couvrent aussi la maîtrise de l’IA au sens du règlement européen sur l’IA. Si basebox devient insolvable, le code sera publié en open source pour que les clients puissent continuer à travailler.
Pas un conseil juridique : ce guide donne une vue d’ensemble, état au 11 octobre 2026. Les obligations qui s’appliquent à votre établissement dépendent de l’usage et de vos contrats.
Questions fréquentes
Un logiciel open source est-il moins sûr qu'un logiciel acheté ?
Pas par principe. Le code source ouvert peut être vérifié, et de nombreux projets corrigent rapidement les failles. Ce qui compte, c'est que quelqu'un suive les avis de sécurité et installe les mises à jour. Avec l'open source, c'est la tâche de l'exploitant.
Faut-il un accord de traitement des données pour une IA exploitée en interne ?
Pas avec les projets open source, car ils ne traitent aucune donnée pour votre compte. Si un prestataire exploite l'environnement pour vous ou y a accès pour la maintenance, il vous faut avec lui un accord de traitement des données au sens de l'art. 28 du RGPD.
basebox utilise-t-elle elle-même de l'open source ?
Oui. basebox repose sur des composants open source, par exemple vLLM pour le modèle d'IA et Keycloak pour l'authentification. Les composants inclus figurent dans la nomenclature logicielle (SBOM). basebox elle-même n'est pas open source.
Sources
- Open Source Initiative : The Open Source Definition ↗
- Apache License 2.0, sections 7 et 8 (exclusion de garantie et de responsabilité) ↗
- MIT License (Open Source Initiative) ↗
- Open WebUI : licence avec clause sur le nom de marque (documentation) ↗
- Règlement (UE) 2016/679 (RGPD), art. 28, 30, 32 et 35 (EUR-Lex) ↗
- Règlement (UE) 2024/1689 (règlement sur l'IA), art. 4 (EUR-Lex) ↗
- Règlement (UE) 2024/2847 (Cyber Resilience Act), art. 24 (EUR-Lex) ↗
Cet article a été créé avec l’aide de l’IA, sur la base des sources citées. Responsable du contenu : basebox GmbH. Ceci n’est pas un conseil juridique, aucune responsabilité. État de la recherche : 11 octobre 2026.