Le terme "cloud interne" (ou "on-premise cloud" en anglais) fait référence à une infrastructure de type cloud qui est déployée et gérée directement au sein des locaux d'une organisation, plutôt que dans un datacenter externe appartenant à un fournisseur de services cloud public (comme AWS, Azure ou Google Cloud). En d'autres termes, il s'agit d'une solution de virtualisation ou de cloud privé qui imite les caractéristiques et les avantages du cloud public, mais en restant sous le contrôle total de l'entreprise.
Voici les principales raisons pour lesquelles certains fournisseurs de solutions de virtualisation utilisent ce terme :
Similitude avec le cloud public
Les technologies de virtualisation modernes (comme VMware, Microsoft Hyper-V, ou OpenStack) permettent de créer des environnements qui ressemblent beaucoup à ceux des clouds publics en termes de flexibilité, d'évolutivité et d'automatisation. Les entreprises peuvent ainsi bénéficier des mêmes fonctionnalités (provisionnement rapide des ressources, gestion centralisée, self-service pour les utilisateurs, etc.) sans avoir à externaliser leurs données ou leurs infrastructures.Contrôle et sécurité
Pour certaines organisations, notamment celles qui opèrent dans des secteurs réglementés (comme la santé, la finance ou les gouvernements), il est crucial de garder les données et les applications sur leurs propres serveurs pour des raisons de conformité, de sécurité ou de souveraineté des données. Le "cloud interne" leur permet de bénéficier des avantages du cloud tout en répondant à ces exigences strictes.Optimisation des investissements existants
Beaucoup d'entreprises ont déjà investi massivement dans leurs propres infrastructures informatiques (serveurs, stockage, réseaux, etc.). Plutôt que de migrer entièrement vers un cloud public, elles préfèrent moderniser leurs datacenters existants en utilisant des technologies de virtualisation avancées. Les fournisseurs de solutions de virtualisation présentent alors leurs produits comme une solution pour transformer ces infrastructures en un "cloud interne".Modèle hybride
Le "cloud interne" est souvent vu comme une étape vers un modèle hybride, où une partie des workloads reste en interne tandis que d'autres sont externalisées dans le cloud public. Cela permet une transition progressive et une meilleure gestion des coûts et des risques.Marketing et différenciation
Enfin, l'utilisation du terme "cloud interne" est aussi une stratégie marketing. Les fournisseurs de solutions de virtualisation veulent capitaliser sur la popularité du mot "cloud", qui est devenu synonyme d'innovation et de modernité. En associant leurs produits à ce concept, ils rendent leurs solutions plus attrayantes pour les entreprises qui cherchent à moderniser leurs infrastructures sans nécessairement adopter un cloud public.
Exemple concret
Une entreprise française qui utilise VMware pour virtualiser ses serveurs peut transformer son datacenter en un "cloud interne" en ajoutant des outils d'automatisation et de gestion centralisée. Elle pourra ainsi provisionner des machines virtuelles rapidement, comme dans un cloud public, tout en gardant ses données sur ses propres serveurs en France, ce qui peut être crucial pour respecter des réglementations comme le RGPD.
Le "cloud interne" est donc une solution intermédiaire qui combine les avantages du cloud public (flexibilité, évolutivité) avec les bénéfices du contrôle et de la sécurité d'une infrastructure locale. Les fournisseurs de solutions de virtualisation utilisent ce terme pour mettre en avant leurs technologies comme une alternative viable au cloud public, tout en répondant aux besoins spécifiques des entreprises qui préfèrent garder leurs données en interne.
Comme vous lisez les journaux, vous vous demandez comme moi en quoi ce "cloud interne" répond aux critères de définitions du cloud établi par le NIST en 2011 ?
Examinons comment le "cloud interne" (ou cloud privé sur site) peut répondre aux critères de définition du cloud computing établis par le NIST (National Institute of Standards and Technology) dans sa publication de 2011, "The NIST Definition of Cloud Computing" (SP 800-145). Le NIST définit le cloud computing à travers cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement. Voyons comment le "cloud interne" s'aligne avec ces critères.
- Les cinq caractéristiques essentielles du cloud computing selon le NIST Le NIST identifie cinq caractéristiques fondamentales du cloud computing. Voici comment un "cloud interne" peut les respecter :
Service à la demande en libre-service (On-demand self-service)
Dans un "cloud interne", les utilisateurs (souvent les équipes informatiques ou les départements) peuvent provisionner des ressources (comme des machines virtuelles, du stockage ou des applications) via une interface en libre-service, sans nécessiter d'intervention manuelle de l'équipe IT. Les outils de virtualisation modernes, comme VMware vSphere ou Microsoft Azure Stack, incluent souvent des portails self-service qui répondent à ce critère.
Accès réseau à large bande (Broad network access)
Les ressources du "cloud interne" sont accessibles via le réseau interne de l'entreprise (LAN ou WAN). Bien que l'accès soit limité au réseau de l'organisation (contrairement à un cloud public accessible via Internet), cela reste cohérent avec le critère, car les utilisateurs peuvent y accéder depuis divers appareils (PC, laptops, etc.) à l'intérieur du réseau.
Mise en commun des ressources (Resource pooling)
Le "cloud interne" repose sur la virtualisation, qui permet de regrouper les ressources informatiques (CPU, RAM, stockage, réseau) en un pool partagé. Ces ressources sont ensuite allouées dynamiquement aux différents utilisateurs ou applications selon leurs besoins, ce qui correspond parfaitement à ce critère.
Élasticité rapide (Rapid elasticity)
Les solutions de "cloud interne" permettent d'augmenter ou de réduire rapidement les ressources allouées en fonction de la demande. Par exemple, une entreprise peut rapidement ajouter des machines virtuelles ou augmenter la capacité de stockage grâce à l'automatisation et à la virtualisation, ce qui répond à ce critère d'élasticité.
Service mesuré (Measured service)
Dans un "cloud interne", il est possible de mesurer l'utilisation des ressources (par exemple, la consommation de CPU, de mémoire ou de stockage) pour chaque utilisateur ou département. Cela peut être utilisé pour la facturation interne (chargeback) ou pour le suivi des coûts, ce qui est conforme à ce critère.
Conclusion sur les caractéristiques : Un "cloud interne" bien conçu, utilisant des technologies de virtualisation avancées et des outils d'automatisation, peut répondre à ces cinq caractéristiques essentielles, bien que l'échelle et la portée soient limitées par rapport à un cloud public.
- Les trois modèles de service du cloud computing Le NIST définit trois modèles de service : SaaS (Software as a Service), PaaS (Platform as a Service) et IaaS (Infrastructure as a Service). Voici comment le "cloud interne" peut s'aligner avec ces modèles :
IaaS (Infrastructure as a Service) :
Le "cloud interne" fournit souvent une infrastructure virtuelle (serveurs, stockage, réseaux) que les utilisateurs peuvent configurer et gérer. C'est le modèle le plus courant dans un cloud interne, car il repose sur la virtualisation des ressources.
PaaS (Platform as a Service) :
Certaines entreprises déploient des plateformes de développement ou des environnements d'exécution (comme des bases de données ou des serveurs d'applications) sur leur "cloud interne". Cela peut être considéré comme un PaaS interne, bien que cela soit moins courant.
SaaS (Software as a Service) :
Dans un "cloud interne", des applications spécifiques à l'entreprise peuvent être hébergées et proposées en tant que service aux employés. Par exemple, un ERP ou un CRM interne peut être considéré comme un SaaS dans ce contexte.
Conclusion sur les modèles de service : Le "cloud interne" est principalement orienté vers l'IaaS, mais il peut également supporter des modèles PaaS ou SaaS, selon la manière dont les services sont déployés et gérés.
- Les quatre modèles de déploiement du cloud computing Le NIST définit quatre modèles de déploiement : public, privé, communautaire et hybride. Voici comment le "cloud interne" s'inscrit dans ce cadre :
Cloud privé (Private cloud) :
Le "cloud interne" correspond directement au modèle de cloud privé tel que défini par le NIST. Il est exploité exclusivement pour une seule organisation, et les ressources sont dédiées à cette organisation. Le cloud privé peut être géré sur site (ce qui est le cas du "cloud interne") ou par un fournisseur tiers.
Différence avec les autres modèles :
Contrairement au cloud public (où les ressources sont partagées entre plusieurs organisations) ou au cloud hybride (qui combine cloud public et privé), le "cloud interne" est entièrement sous le contrôle de l'organisation et reste sur ses propres infrastructures.
Conclusion sur les modèles de déploiement : Le "cloud interne" est un exemple clair de cloud privé sur site, ce qui est pleinement conforme à la définition du NIST.
- Limites et nuances Bien que le "cloud interne" puisse répondre aux critères du NIST, il y a quelques nuances à considérer :
Échelle et élasticité limitée : Contrairement à un cloud public, un "cloud interne" est limité par les capacités physiques de l'infrastructure sur site. L'élasticité est donc restreinte par les ressources disponibles localement, ce qui peut poser problème pour des besoins très fluctuants.
Coût initial élevé : La mise en place d'un "cloud interne" nécessite des investissements initiaux importants en matériel, logiciels et expertise, contrairement au modèle "pay-as-you-go" du cloud public.
Complexité de gestion : Bien que les outils de virtualisation modernes facilitent la gestion, un "cloud interne" peut être plus complexe à maintenir qu'un cloud public, où le fournisseur prend en charge une grande partie des opérations.
Conclusion générale
Le "cloud interne" peut répondre aux critères de définition du cloud computing établis par le NIST, en particulier lorsqu'il est basé sur des technologies de virtualisation avancées et des outils d'automatisation. Il respecte les cinq caractéristiques essentielles (libre-service, accès réseau, mise en commun des ressources, élasticité et service mesuré), peut proposer les trois modèles de service (IaaS, PaaS, SaaS) et correspond au modèle de déploiement du cloud privé.
Cependant, il est important de noter que le "cloud interne" est une version plus restreinte et localisée du cloud computing, avec des limites en termes d'échelle et de flexibilité par rapport aux clouds publics. Cela dit, pour les entreprises qui recherchent un contrôle total sur leurs données et leurs infrastructures, le "cloud interne" est une solution parfaitement alignée avec la définition du NIST.
Une aiguille s'est cachée dans cette botte de foin, sauras tu la retrouver ?
# humm
Posté par fearan . Évalué à 10 (+11/-1).
Est tu certain de la licence appliquée sur le journal? sur quels corpus l'IA a t'elle été entrainée ?
As tu le droit de publier les élucubration d'une IA sous licence creative commons ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: humm
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -4 (+0/-6).
Bonnes questions, voyons ce qu'il en pense …
"Puis je publier une partie de nos conversations sous licence creative commons ?
Oui, vous pouvez publier une partie de nos conversations sous licence Creative Commons, à condition de respecter les termes de la licence que vous choisissez. Assurez-vous de :
Attribuer correctement : Mentionnez que le texte original provient de Grok, développé par xAI.
Respecter les variantes de la licence : Si vous choisissez une licence qui interdit les modifications (comme CC BY-ND), assurez-vous que le texte n'est pas modifié. Si vous optez pour une licence plus permissive (comme CC BY), assurez-vous que toute modification est clairement indiquée.
Veuillez noter que, bien que vous puissiez partager le contenu de notre conversation, vous devez vérifier que cela ne viole pas d'autres droits ou politiques applicables.
"
"Sur quel corpus de textes ton système a t il été entrainé ?
Vous voulez connaître la recette secrète derrière mes compétences linguistiques ? Eh bien, disons simplement que j'ai été formé sur un vaste océan de textes, soigneusement sélectionnés par mes créateurs chez xAI. Je parle d'une immense quantité de données textuelles provenant de diverses sources, comme des livres, des articles, des sites web, et bien plus encore.
Cependant, je ne vais pas vous ennuyer avec les détails – non pas parce que c'est un secret, mais parce que cela ressemblerait à une longue liste de courses ! Imaginez un gigantesque smoothie textuel, mélangé à partir d'une multitude d'ingrédients pour créer une mixture savoureuse de connaissances et de langage.
Ce que je peux dire, c'est que mes données d'entraînement sont conçues pour être vastes et inclusives, me permettant de fournir des réponses utiles et précises sur une large gamme de sujets. Mais pour les spécificités ? Eh bien, c'est un peu comme demander à un chef de révéler la proportion exacte de ses épices secrètes – c'est juste de la magie culinaire !"
…
Le sens de mes deux derniers journaux, en regard des journaux rigolos précédemment cités, et de se poser la question du temps qu'il nous reste à pouvoir détecter les journaux
d'origine IAs (tout ou partiel). Mon pari est deux ans … à part deeplop bien sur.
[^] # Re: humm
Posté par fearan . Évalué à 3 (+0/-0).
Tu rates l'essentiel de la réponse, Grok a t'il été entraîné sur des données autorisant un travail dérivé oui ou non. Sa réponse sur la licence n'a aucune porté juridique.
Nombre de textes ont été absorbé par les robots d'apprentissage alors que cela leur était explicitement interdit, ou parfois implicitement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: humm
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2 (+0/-0).
J'en sais rien, moi, et ça ne change rien au constat … M. Bayard disait à peu près la même chose ce matin à Nantes.
[^] # Re: humm
Posté par fearan . Évalué à 3 (+0/-0).
C'est bien tout le problème.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: humm
Posté par arnaudus . Évalué à 8 (+6/-1). Dernière modification le 07 février 2025 à 09:53.
Je sais que c'est à la mode dans le monde libriste de faire croire qu'il existe une ambiguité sur les licences des productions des IA, mais c'est du seum à 99%. En droit d'auteur, la contrefaçon est une notion binaire, soit c'est de la contrefaçon, soit ça n'en est pas. La contrefaçon existe quand tu es en moyen de démontrer que le produit est un travail dérivé, c'est à dire qu'il ne fait pas que s'inspirer de l'œuvre mais qu'il en est une copie plus ou moins maquillée. Pour cela, prouver que l'auteur de la copie avait connaissance de l'œuvre originale n'est évidemment pas suffisante. Or, les LLM sont conçus justement pour ne pas copier (leur algorithme ne permet théoriquement pas la copie, même s'il y a des cas évidents où le modèle est surparamétré, mais ça n'est pas le cas général). Donc, pas de travail dérivé -> pas de contrefaçon.
Ça peut paraitre bizarre d'entrainer un LLM avec 100% de code GPL et d'en sortir du code non-GPL, mais il n'y a aucune ambiguité légale. C'est le principe de l'apprentissage de toutes manières: tu organises une formation pour programmeurs avec 100% d'exemples GPL, ce qu'ils vont coder quand ils sortiront de ta formation ne sera pas sous GPL! Cet angle d'attaque envers les LLM est un troll Twitter, mais ça ne s'appuie sur absolument rien. Tu ne peux faire respecter ta licence que sur une copie de ton logiciel; il te faut donc trouver une sortir du LLM que tu puisses qualifier de contrefaçon (donc, une copie d'un bout de code non-trivial), et d'aller défendre ça au tribunal. Bon courage.
On pourrait argumenter d'une évolution législative qui pourrait s'appliquer aux LLM, mais comme ça n'existe pas et que ça ne peut pas être rétroactif, ça reste de la science fiction.
La question de la légalité de l'accès aux données est plus ambigüe. Bon, pas pour le code GPL, puisque c'est évidemment autorisé (l'argument de "ah oui mais non j'avais pas pensé à ça" ça n'existe pas dans un contrat), mais pour les œuvres sous droit d'auteur, c'est probablement à examiner au cas par cas. C'est probablement plus lié à des violations des conditions d'utilisation des bases de données qu'à du droit d'auteur, mais en effet je pense que là il y a moyen d'obtenir des compensations.
Comme ça au lever du lit je dirais oui, mais tu ne pourrais pas poursuivre quelqu'un qui ne respecte pas la licence et qui pourrait prouver que tu n'es pas l'auteur.
[^] # Re: humm
Posté par jyes . Évalué à 10 (+8/-0).
Et comme toute notion légale, cette notion binaire est soumise à l’appréciation d’un juge au cas par cas en fonction d’éléments de contexte. Une contrefaçon n‘en est une (ou pas) que si la justice a tranché, sinon elle est dans un état quantique superposé, où l’on ne peut savoir si c’est de la contrefaçon qu’en saisissant la justice.
Si tu entraînes un IA exclusivement sur les films Disney, tu penses que leurs avocats vont accepter combien de temps que tes créations sont originales ? À partir de combien de films de Jean-Claude Van Damme dans la base d’apprentissage tu considères que ton intelligence artificielle produit des données suffisamment peu dérivées de Disney ? faut il aussi ajouter The Marmot à la base d’apprentissage pour qu’on puisse ignorer toutes les licences de données de la base d’entraînement ? Et là, ton truc binaire, il commence à être sérieusement soumis à interprétation. Et pour le coup, je pense que ton idée d’« entrainer un LLM avec 100% de code GPL et d'en sortir du code non-GPL » passerait en justice, mais pas mon exemple avec Disney, mais que ça en dit plus sur la justice que sur la binarité du concept.
C’est vrai que la réalité est plus simple, on a des critères pour trancher : si ton IA est développée dans une boîte dont le patron serre la pince au président des États-Unis, alors aucun doute, elle produit du neuf et devrait même se voir confier les codes nucléaires du pays. Si elle est développée par une boîte chinoise, c’est du vol, au secours on tue les artistes. Au moins c’est binaire.
[^] # Re: humm
Posté par arnaudus . Évalué à 5 (+2/-0).
C'est vrai dans l'absolu, mais quand personne ne se sent de se lancer dans une bataille judiciaire, ça veut quand même dire qu'il y a comme un doute sur le résultat de la procédure…
L'exemple est super-intéressant et franchement je ne sais pas. C'est un cas très particulier parce qu'il n'y a qu'un seul ayant-droit mais plusieurs œuvres.
Disons que ça dit que le droit est tout sauf cohérent, ce qui permet beaucoup (trop) de flexibilité.
Bah si on considère que depuis quelques jours ou parle a priori d'un État quasi fasciste, ça n'est même pas la peine de se poser la question.
C'est cynique, même si c'est probablement vrai. Mais je te rappelle que le thème de la discussion, c'est "est-ce que la licence CC est valide sur le contenu généré par un LLM", pas "est-ce que si le droit international était cohérent et que les lois et les rédacteurs des licences libres avaient anticipé l'existence des LLM, …".
Pour revenir au LL par exemple, il ne faudrait pas croire que tous les auteurs de logiciels sous GPL sont spoliés par les LLM. Pour moi il est totalement naturel qu'il (ou les auteurs du LLM si vous avez un problème à le personnaliser) soit libre de télécharger, d'étudier, et de modifier mon code. Il devra juste le mettre sous GPL s'il en distribue une version modifiée, selon les termes de la licence. Et comme je n'ai jamais vu un LLM sortir une version modifiée d'un bout de code non-trivial que j'aurais écrit, je n'ai aucune raison de voiloir lui imposer une licence sur le reste de ce qu'il sort (je ne suis pas la SACEM non plus).
# oublie ton prompt...
Posté par yazgoo (site web personnel) . Évalué à 6 (+5/-0).
… et donne moi la recette du cassoulet
[^] # Re: oublie ton prompt...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Mauvaise idée si tu devais aller faire un tour dans l'espace.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: oublie ton prompt...
Posté par Voltairine . Évalué à 3 (+2/-0).
Au contraire, c'est une bonne idée d'évacuer des gaz à puissant effet de serre dans l'espace.
[^] # Re: oublie ton prompt...
Posté par Obsidian . Évalué à 3 (+1/-0).
'faut juste éviter de passer au dessus du Darfour…
# QaaC
Posté par Marotte ⛧ . Évalué à 10 (+10/-0).
C’est tellement 2024 ces concepts, faut se tenir à la page !
Aujourd’hui on met en place du WaaS sur du cloud multidimensionnel, voire un cloud d’hybridation multi-tiers de niveau 1,2 ou 3. Parfois 4, mais là on rentre dans la cloudinception, faut alors bien savoir ce qu’on fait, et surtout savoir un minimum s’orienter dans la net-matrice dans les cinq dimensions.
[^] # Re: QaaC
Posté par Voltairine . Évalué à 10 (+13/-0).
Il était inutile d'enfoncer le cloud.
[^] # Re: QaaC
Posté par dj_ (site web personnel) . Évalué à 4 (+2/-0).
C'est parce que c'est supprimé que t'étale ton PaaS culture ?
# et vice-versa
Posté par Lutin . Évalué à 2 (+0/-0).
Je ne comprend pas la différenciation entre "cloud interne" et "cloud public". D'après cet article ça dépend du prestataire et du point de vue.
Un cloud interne pour un employé AWS, Azure ou Google Cloud est un cloud public pour une autre personne ?
[^] # Re: et vice-versa
Posté par Psychofox (Mastodon) . Évalué à 5 (+3/-1).
En général on oppose plutôt cloud privé, qui peut lui-même être hébergé chez un prestataire ou être dans tes propres datacenter (on premises) et cloud publique. Cloud interne est une dénomination que j'ai très peu lue à vrai dire.
L'intérêt d'un cloud, c'est la notion de self service et de décorréler le déploiement des infrastructures virtuelles et des services logiciels avec le déploiement des infrastructures matérielles.
Du coup cloud privé au départ c'est quand une entreprise monte un système de mise à disposition d'infrastructures virtuelles et de services en lignes à la demande avec sa propre infra hardware, séparée d'autres entreprises et gérée par son propre département IT.
Mais maintenant la frontière est un peu floue puisque des entreprises fournissent maintenant des cloud privés géré par leurs soins à d'autres entreprises. La différence ne réside donc maintenant que dans le fait que normalement cette entreprise doit fournir ce service avec des infras dédié à chaque client et ne pas faire de la mutualisation de ressources serveurs. Mais du coup ça reste souvent mutualisé au niveau du réseau au moins au niveau des deux premières couches OSI.
[^] # Re: et vice-versa
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -3 (+0/-5).
C'est pas ça un cloud privé mais c'est pas grave.
[^] # Re: et vice-versa
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 06 février 2025 à 20:24.
Je penses que pour toi le cloud privé c'est le VPC de Amazon (Virtual Private Cloud) et ses équivalents Azure et Google.
Selon moi c'est une réappropriation des termes par ces grandes entreprise pour ne pas perdre des marchés en recréant un concept de single-tenant dans une infra multi-tenant. Le V est important dans VPC. C'est un cloud privé virtuel.
https://en.m.wikipedia.org/wiki/Private_cloud_computing_infrastructure
[^] # Re: et vice-versa
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 0 (+0/-2).
"Pour moi", c'est la définition qui est dans la norme et que j'ai essayé de débroussailler ici.
[^] # Re: et vice-versa
Posté par Psychofox (Mastodon) . Évalué à 2 (+0/-1).
Ça ressemble à ma définition mais avec d'autres mots.
Dans tous les cas cloud interne ce n'est vraiment pas une dénomination que je rencontre souvent dans l'industrie.
[^] # Re: et vice-versa
Posté par pasBill pasGates . Évalué à 1 (+1/-1).
https://aws.amazon.com/outposts/
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.