Qualification et inventaire
JRbIA maintient un inventaire proportionné des composants, versions, licences, provenances et services matériels à l’offre. Une dépendance de développement, un composant livré, un fournisseur envisagé, un connecteur préparé et un sous-traitant actif ne sont pas confondus. Les dépendances critiques sont identifiées avec leur fonction et leur solution de continuité.
Nomenclature logicielle
Lorsque le risque ou l’offre le justifie, une nomenclature des composants — SBOM ou registre équivalent — relie le composant, sa version, sa source, sa licence, ses dépendances et son statut de support. Elle constitue un outil de transparence et de sécurité, non une garantie d’absence de vulnérabilité.
Licences open source
Les composants open source restent soumis à leur licence. Les avis, attributions, textes, mentions de modification, offres de code source et obligations de mise à disposition sont conservés et remis lorsque requis. La compatibilité des licences est contrôlée avant distribution ; les CGV JRbIA ne retirent pas les droits directement accordés par une licence libre.
Composants propriétaires et droits d’usage
Un composant propriétaire n’est intégré ou redistribué que dans la limite des droits obtenus. Le contrat précise les restrictions matérielles : utilisateurs, instances, territoire, durée, environnement, sauvegarde et transfert. Une restriction contractuelle ne neutralise pas une exception impérative prévue par la loi.
Services et API externes
Le client respecte les conditions du service qu’il choisit de connecter. JRbIA documente les comptes, autorisations, quotas, coûts, régions, limites, versions d’API et dépendances connus, sans garantir qu’un tiers maintiendra indéfiniment son API, son prix, ses fonctions ou sa compatibilité.
Activation d’un connecteur
Un connecteur n’est déclaré actif qu’après configuration, autorisation, test limité, contrôle du périmètre de données et recette. Un secret enregistré, un bouton visible ou une fiche fournisseur ne constitue pas une connexion opérationnelle. Les droits demandés suivent le moindre privilège et peuvent être révoqués.
Données confiées à un tiers
Avant transfert, JRbIA qualifie les données, finalités, rôles, localisation, conservation, entraînement éventuel, sous-traitants et mécanismes de suppression ou d’export. Un fournisseur technique ne reçoit pas par défaut le droit d’utiliser les données, contenus, requêtes ou résultats pour ses propres finalités.
Changements du fournisseur
Les modifications matérielles de conditions, prix, API, régions, sous-traitants, sécurité ou politiques de données sont évaluées selon leur impact. Elles ne sont pas automatiquement répercutées au client lorsqu’elles modifient son contrat ou ses droits ; une adaptation, un préavis ou un accord est organisé selon le cas.
Sécurité de la chaîne
Les sources, versions, empreintes, vulnérabilités, dépendances transitives et mises à jour critiques sont suivies selon le risque. Une dépendance compromise ou abandonnée peut être désactivée, corrigée, remplacée ou isolée. Aucun paquet, dépôt ou fournisseur n’est déclaré sûr par nature.
Gestion des vulnérabilités
Les composants suivent la politique Vulnérabilités, correctifs et divulgation coordonnée. Un signalement est relié aux versions réellement utilisées puis traité selon son exploitabilité, son exposition et les mesures compensatoires. JRbIA préserve les éléments utiles et informe les parties concernées lorsque requis.
Droits et interopérabilité
Le client ne contourne pas les limitations, n’extrait pas un code non fourni et ne revend pas un service sans droit. Ces restrictions ne s’appliquent pas lorsqu’une loi ou une licence autorise expressément sauvegarde, observation, étude, test ou actes nécessaires à l’interopérabilité dans leurs conditions légales.
Support et fin de vie
Les versions supportées, correctifs, dates de fin de support et dépendances essentielles sont documentés lorsqu’ils déterminent l’offre. Une version obsolète n’est pas maintenue indéfiniment, mais sa fin de support fait l’objet d’un préavis adapté au risque et aux engagements souscrits.
Fin de dépendance et réversibilité
En cas de retrait, suspension ou changement incompatible, JRbIA évalue remplacement, export, mode dégradé, retour arrière ou cessation de la fonction. Les données et configurations récupérables sont restituées selon le contrat. Les conséquences commerciales suivent l’importance de la fonction, la cause et les engagements souscrits.
Porte de validation
Avant mise en production : provenance, licence, droits de distribution, version, maintenance, vulnérabilités, données, régions, sous-traitants, permissions, quotas, coût, dépendance critique, continuité, export et fin de support sont contrôlés. Une dépendance non qualifiée reste limitée à l’étude ou à l’environnement d’essai.