De toutes les façons, depuis les années 2000, l'informatique de la SNCF et en particulier celle de la SNCF s'est complètement "américanisée".
Je ne sais pas pour vous cher lecteur, mais oui.sncf, auparavant voyages sncf, est une agence de voyage, et je trouve la situation assez schizophrénique.
Cette agence de voyage est une filiale non pas de la SNCF, mais de la SNCF et d'Expedia.
Vous trouverez tous les détails à partir du point 22 de la décision 09-D-06 du Conseil de la Concurrence devenue depuis Autorité de la Concurrence.
Autrement dit, pour assurer la "partie" informatique de son activité de vente de ticket de trains, la SNCF a fait appel à son principal concurrent, également agence de voyages : Expedia.
C'est d'ailleurs ce qui explique que lorsque vous achetez un ticket de train, on vous propose en plus du ticket de train tout un tas de location de voitures, d’hôtels, d'expéditions ….
Ce passage à Amazon serait il le second étage de la fusée telle que "dessinée" dans les plans de notre start'up nation ?
Le troisième étage devrait être le rachat par Expedia de la totalité de Oui.sncf.
Parce que ce grand remplacement sera beaucoup mieux ;-)
As-tu lu l'article? Le titre est pourri ("plébisciter", ça veut dire "choisi par le peuple", c'est complètement con dans le contexte), mais l'article égrène des arguments, si les anglicismes de "dissailledeurze" ne nous font pas trop saigner des yeux.
Les arguments principaux, si j'ai bien compris, sont:
* La tolérance aux pannes
* La gestion des pics de connexion
Bah voila, ça semble logique. C'est évident que pour gérer les pics, c'est plus facile de louer quelques serveurs supplémentaires que de les acheter, surtout s'ils sont destinés à ne servir qu'1% du temps.
Gérer son propre parc, ça a un coût, surtout si on a besoin d'une certaine résilience. Ça ne semble pas irrationnel d'externaliser ce genre de choses.
Après, j'ai toujours pensé que la SNCF se fourvoyait avec son modèle calqué sur les billets d'avion. Elle se met toute seule en concurrence avec l'avion, et elle n'a pas moyen d'être compétitive, ce qui la conduit vers une course en avant et la baisse de qualité de service—les TGV low-cost sont une cata pour l'image de la SNCF. Mais ça n'a rien à voir avec l'hébergement de son infrastructure. De toutes manières, la SNCF n'a jamais su vendre des billets de train; ses sites ont toujours été pourris, ses guichets toujours aussi encombrés et inutiles… Ce n'est pas un changement d'hébergeur qui va révolutionner ça.
oui, gérer son propre parc cela à un coût. Et alors ?
L'informatique, c'est comme l'immobilier : il vaut mieux un petit chez soi qu'un grand chez les autres ;-)
Posté par Renault (site web personnel) .
Évalué à 7.
Dernière modification le 10 décembre 2021 à 12:23.
L'informatique, c'est comme l'immobilier : il vaut mieux un petit chez soi qu'un grand chez les autres ;-)
Bah, non, dans les deux cas ça dépend des situations et besoins de chacun. Être locataire de son logement pour le particulier ou de ses locaux pour une entreprise ça a aussi du sens et des avantages.
La SNCF n'est pas une entreprise d'informatique, sa valeur ajoutée et son cœur de métier est dans les liaisons ferroviaires. L'informatique est un moyen de réaliser son travail, mais tout comme la SNCF ne crée pas ses propres trains dont elle dépend, il n'y a pas de raison qu'elle maitrise tout son parc informatique.
Sinon les fournisseurs n'existeraient pas, car il faudrait maitriser toute sa chaine de production à chaque fois ce qui pose aussi des problèmes.
Construire une grosse infra pour un site comme celui-là ne s'improvise pas et ce n'est pas le métier de la SNCF de le faire. Or comme il y a des fournisseurs qui le font bien à un tarif acceptable, aller ailleurs fait sens. Le faire en interne n'est pas tellement justifié ici, la SNCF n'a pas des besoins qu'un hébergeur comme Amazon ne sait pas prendre en charge.
Posté par Pinaraf .
Évalué à 10.
Dernière modification le 10 décembre 2021 à 12:39.
La SNCF n'est pas une entreprise d'informatique, sa valeur ajoutée et son cœur de métier est dans les liaisons ferroviaires.
L'article ne parle pas de la SNCF mais de sa filiale, oui.sncf, qui est une agence de voyages, SAS filiale de la SNCF.
Du coup, sa valeur ajoutée et son cœur de métier, c'est la fourniture de «services de réservation et activités connexes». Donc la vente de billets en lignes. Donc c'est une entreprise d'informatique.
Or comme il y a des fournisseurs qui le font bien à un tarif acceptable, aller ailleurs fait sens. Le faire en interne n'est pas tellement justifié ici, la SNCF n'a pas des besoins qu'un hébergeur comme Amazon ne sait pas prendre en charge.
Le coût n'est pas un critère. La colonne dans laquelle ranger le coût est bien plus importante. Au lieu d'avoir des immobilisations matérielles pour X€ et des salaires pour Y€, on préfère payer Z€ en frais de prestation de services, quitte à ce que Z soit largement supérieur à X + Y (ou alors oui.sncf est une exception) … Parce que la logique comptable, la logique de dirigeants d'entreprises privées, n'est pas basée sur un coût mais sur sa classification.
L'article ne parle pas de la SNCF mais de sa filiale, oui.sncf, qui est une agence de voyages, SAS filiale de la SNCF.
Du coup, sa valeur ajoutée et son cœur de métier, c'est la fourniture de «services de réservation et activités connexes». Donc la vente de billets en lignes. Donc c'est une entreprise d'informatique.
La valeur ajoutée est le site web et l'applicatif, pas l'hébergement de ce service dans un datacenter qui est une autre compétence.
Le coût n'est pas un critère. La colonne dans laquelle ranger le coût est bien plus importante. Au lieu d'avoir des immobilisations matérielles pour X€ et des salaires pour Y€, on préfère payer Z€ en frais de prestation de services, quitte à ce que Z soit largement supérieur à X + Y (ou alors oui.sncf est une exception) … Parce que la logique comptable, la logique de dirigeants d'entreprises privées, n'est pas basée sur un coût mais sur sa classification.
Il faut déjà démontrer que Z > X + Y, ce n'est pas si simple.
Oui Amazon marge, mais on le sait bien que ce secteur d'activité fonctionne avec des pics et des creux. Il y a des périodes où oui.scnf reçoit beaucoup de requêtes (en journée en France et à l'approche des vacances) et d'autres où c'est le néant comme la nuit en France.
Donc pour gérer ces pics de charge, oui.sncf doit surdimensionner son infra. Ou renoncer à servir convenablement les clients durant ces pics (c'est un choix mais coûteux aussi). De plus il a besoin d'une armée d'admin sys capables de gérer une telle infra dans les règles de l'art, ce n'est pas si facile à trouver.
Amazon (ou un autre prestataire du genre) peut mutualiser les machines entre différents clients pour gérer les pics des différents clients sans trop surdimensionner l'ensemble. Donc on réduit les coûts en matériel, en énergie et en espace. De plus, de part leur métier avec AWS, ils ont les compétences en interne pour maintenir cette infra. C'est leur boulot et le feront probablement mieux que n'importe quelle équipe constituée par oui.sncf de manière adhoc.
Donc oui, j'insiste : chacun son métier, l'intégration verticale ça peut fonctionner mais ce n'est pas un absolu.
Posté par MrBidon .
Évalué à 9.
Dernière modification le 10 décembre 2021 à 13:47.
L'argument pourri de la résilience et des pics de charges pour justifier le choix d'aller chez l'oncle SAM… Rien ne les empêche d'avoir des hébergements chez plusieurs cloud européens comme OVH, Hetzner ou Scaleway pour avoir de la résilience. Des loadbalanceurs, ça se met bien en place par chez nous aussi.
Une décision comme celle-ci est agaçante, car on est sur un choix classique de DSI d'entreprise publique qui migre par défaut vers un cloud US à la mode (on entend aussi souvent parler de Azure, AWS ou Google) suite à du lobying. J'avais fais une comparaison entre AWS et OVH on est 4 fois plus cher. Avec l'argent économisé, on peut largement payer de la R&D pour combler l'écart entre AWS et le cloud Européen.
L'argument pourri de la résilience et des pics de charges pour justifier le choix d'aller chez l'oncle SAM… Rien ne les empêche d'avoir des hébergement chez plusieurs cloud européens comme OVH, Hetzner ou Scaleway pour avoir de la résilience. Des loadbalanceurs, ça se met bien en place par chez nous aussi.
Je répondais à l'argument d'avoir tout en interne sous contrôle, je n'ai pas dit que Amazon était un meilleur choix que OVH, mais que Amazon était probablement un meilleur choix que de tout internaliser. Ce n'est pas pareil.
Je ne connais pas bien les acteurs pour me prononcer au delà de ce que j'ai dit.
Et le tout sans parler du fait que le Safe Harbour a été invalidé, que le Privacy Shield a aussi été invalidé et qu'à l'heure actuelle la base juridique pour opérer un tel transfert de données n'est pas sans risque !!! N'oublions pas non plus le Cloud Act et l'extra-territorialité du droit US (et me parlez pas de la localisation des serveurs en Europe …).
Prendre le train, cela va désormais me "coûter cher" :-(
La valeur ajoutée est le site web et l'applicatif, pas l'hébergement de ce service dans un datacenter qui est une autre compétence.
C'est étonnant, pourquoi l'hébergement est différent du développement ? Ils n'ont qu'à sous-traiter le développement à Atos, Capgemini ou n'importe quelle SSII.
Et au passage, y'a pas que le «cloud» et sa gestion de VMs comme solution. Tu peux passer par des tas d'intermédiaires qui te louent N baies et le réseau qui va bien. Ou tu peux louer des serveurs dédiés chez OVH, Scaleway ou autre. Ou tu peux prendre le «cloud privé» d'OVH ou autre, offres qui normalement te permettent d'ajouter des machines en quelques clics, mais où tu choisis encore comment tu gères tes VMs. Etc, etc…
La colonne dans laquelle ranger le coût est bien plus importante. Au lieu d'avoir des immobilisations matérielles […] et des salaires […], on préfère [les] prestation de services
J'avoue que j'ai jamais trop compris pourquoi des entreprises préfèrent ce fonctionnement (pas trop cherché non plus). CAPEX vs OPEX si j'ai bien suivi le verbiage. Si quelqu'un a une résumé, ça intéresse.
Capex: il faut sortir beaucoup de thune là maintenant tout de suite et amortir sur des années: on n'aime bas ça, parce que l'année de la dépense, les comptes ne seront pas jolis.
Opex: on étale la dépense sans faire aucune vague sur le budget annuel, du coup les années se ressemblent.
Maintenant, je ne sais pas de quel Capex on parle ici, je suis dans les semi-conducteurs, et c'est une industrie à gros Capex, qui finit par devenir récurrent quand on devient assez gros, d'où l'externalisation grandissante des procédés de fabrication vers des fondeurs toujours plus gros eux aussi (et on ne parle même pas encore de la course a la finesse de gravure).
Posté par GG (site web personnel) .
Évalué à 3.
Dernière modification le 11 décembre 2021 à 18:52.
Certes, mais tu peux toujours faire une provision, avec étalement.
D'ailleurs, les grosses dépenses sont prises en comptes avec étalements, parce que ce sont des investissements.
Mais, c'est vrai qu'au niveau comptable, une facture de prestation, c'est noyé avec le reste, et donc pas d'amortissements.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
La SNCF préfère héberger le datacenter de la ville de Paris, qui pourra stocker aussi les données de l'APHP, Paris Habitat ou Eaux de Paris … mais pas les données de la SNCF, c'est ballot …
2024, le président américain appelle le président français:
Allo Jean Luc, c'est Trump Junior, ça roule?
Je suis sur mon brouillon de VI° République, je pense rétablir le service militaire, qu'en penses-tu?
Good idea ! Ca tombe bien je voulais t'inviter pour la nouvelle guerre contre la Bhoutan.
Hein ils ont fait quoi?
Rien mais après les échecs au Vietnam, en Irak, en Afghanistan, en Irak, en Iran et puis en Irak, j'aurais besoin d'une victoire pour les élections de mi mandat.
Mais c'est complètement con !
Peut être, mais si tu n'envoies pas des troupes, je demande à Amazon de couper les serveurs de la SNCF, de la sécu, des impôts.
Bon ok, j'envoie le Charles de Gaulle 2.0 …
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par mahikeulbody .
Évalué à 4.
Dernière modification le 10 décembre 2021 à 18:44.
Souverain mais piloté par Microsoft ou Amazon non ?
Non, cette étape-là, ça sera en 2026 après l'échec du projet "cloud souverain franco-européen" pour cause de mésentente entre les différents partenaires (qui se garderont néanmoins de rendre les sous des subventions publiques).
Ah, on me souffle dans l'oreillette qu'on serait déjà en 2026, en fait.
Pour être précis non ce n'est pas piloté par des gafam. Le cloud souverain dont on entend parler depuis quelques mois, c'est des français qui prennent des machines américaines ou asiatiques, les installent sur le territoire français et font tourner dessus du logiciel américain (littéralement faire tourner azure etc).
Donc ça n'a de souverain que l'accès aux machines physiques. C'est une incompréhension totale de ce qu'est le logiciel, c'est un doigt d'honneur fait aux vrais acteurs français de cloud et bien sûr le contrôle américain reste totale (c'est probablement encore plus rentable pour Microsoft de louer ses logiciels sans avoir à s'emmerder avec la gestion des machines). Au final on leur donne de l'argent et des parts de marché (le lock in vient du logiciel) au lieu d'aider les acteurs souverain.
# Qu'à moitié étonné
Posté par TuxMips . Évalué à 10.
De toutes les façons, depuis les années 2000, l'informatique de la SNCF et en particulier celle de la SNCF s'est complètement "américanisée".
Je ne sais pas pour vous cher lecteur, mais oui.sncf, auparavant voyages sncf, est une agence de voyage, et je trouve la situation assez schizophrénique.
Cette agence de voyage est une filiale non pas de la SNCF, mais de la SNCF et d'Expedia.
Vous trouverez tous les détails à partir du point 22 de la décision 09-D-06 du Conseil de la Concurrence devenue depuis Autorité de la Concurrence.
Autrement dit, pour assurer la "partie" informatique de son activité de vente de ticket de trains, la SNCF a fait appel à son principal concurrent, également agence de voyages : Expedia.
C'est d'ailleurs ce qui explique que lorsque vous achetez un ticket de train, on vous propose en plus du ticket de train tout un tas de location de voitures, d’hôtels, d'expéditions ….
Ce passage à Amazon serait il le second étage de la fusée telle que "dessinée" dans les plans de notre start'up nation ?
Le troisième étage devrait être le rachat par Expedia de la totalité de Oui.sncf.
Parce que ce grand remplacement sera beaucoup mieux ;-)
[^] # Re: Qu'à moitié étonné
Posté par arnaudus . Évalué à 6.
As-tu lu l'article? Le titre est pourri ("plébisciter", ça veut dire "choisi par le peuple", c'est complètement con dans le contexte), mais l'article égrène des arguments, si les anglicismes de "dissailledeurze" ne nous font pas trop saigner des yeux.
Les arguments principaux, si j'ai bien compris, sont:
* La tolérance aux pannes
* La gestion des pics de connexion
Bah voila, ça semble logique. C'est évident que pour gérer les pics, c'est plus facile de louer quelques serveurs supplémentaires que de les acheter, surtout s'ils sont destinés à ne servir qu'1% du temps.
Gérer son propre parc, ça a un coût, surtout si on a besoin d'une certaine résilience. Ça ne semble pas irrationnel d'externaliser ce genre de choses.
Après, j'ai toujours pensé que la SNCF se fourvoyait avec son modèle calqué sur les billets d'avion. Elle se met toute seule en concurrence avec l'avion, et elle n'a pas moyen d'être compétitive, ce qui la conduit vers une course en avant et la baisse de qualité de service—les TGV low-cost sont une cata pour l'image de la SNCF. Mais ça n'a rien à voir avec l'hébergement de son infrastructure. De toutes manières, la SNCF n'a jamais su vendre des billets de train; ses sites ont toujours été pourris, ses guichets toujours aussi encombrés et inutiles… Ce n'est pas un changement d'hébergeur qui va révolutionner ça.
[^] # Re: Qu'à moitié étonné
Posté par TuxMips . Évalué à 3.
oui, gérer son propre parc cela à un coût. Et alors ?
L'informatique, c'est comme l'immobilier : il vaut mieux un petit chez soi qu'un grand chez les autres ;-)
[^] # Re: Qu'à moitié étonné
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 10 décembre 2021 à 12:23.
Bah, non, dans les deux cas ça dépend des situations et besoins de chacun. Être locataire de son logement pour le particulier ou de ses locaux pour une entreprise ça a aussi du sens et des avantages.
La SNCF n'est pas une entreprise d'informatique, sa valeur ajoutée et son cœur de métier est dans les liaisons ferroviaires. L'informatique est un moyen de réaliser son travail, mais tout comme la SNCF ne crée pas ses propres trains dont elle dépend, il n'y a pas de raison qu'elle maitrise tout son parc informatique.
Sinon les fournisseurs n'existeraient pas, car il faudrait maitriser toute sa chaine de production à chaque fois ce qui pose aussi des problèmes.
Construire une grosse infra pour un site comme celui-là ne s'improvise pas et ce n'est pas le métier de la SNCF de le faire. Or comme il y a des fournisseurs qui le font bien à un tarif acceptable, aller ailleurs fait sens. Le faire en interne n'est pas tellement justifié ici, la SNCF n'a pas des besoins qu'un hébergeur comme Amazon ne sait pas prendre en charge.
[^] # Re: Qu'à moitié étonné
Posté par Pinaraf . Évalué à 10. Dernière modification le 10 décembre 2021 à 12:39.
L'article ne parle pas de la SNCF mais de sa filiale, oui.sncf, qui est une agence de voyages, SAS filiale de la SNCF.
Du coup, sa valeur ajoutée et son cœur de métier, c'est la fourniture de «services de réservation et activités connexes». Donc la vente de billets en lignes. Donc c'est une entreprise d'informatique.
Le coût n'est pas un critère. La colonne dans laquelle ranger le coût est bien plus importante. Au lieu d'avoir des immobilisations matérielles pour X€ et des salaires pour Y€, on préfère payer Z€ en frais de prestation de services, quitte à ce que Z soit largement supérieur à X + Y (ou alors oui.sncf est une exception) … Parce que la logique comptable, la logique de dirigeants d'entreprises privées, n'est pas basée sur un coût mais sur sa classification.
[^] # Re: Qu'à moitié étonné
Posté par Renault (site web personnel) . Évalué à 4.
La valeur ajoutée est le site web et l'applicatif, pas l'hébergement de ce service dans un datacenter qui est une autre compétence.
Il faut déjà démontrer que Z > X + Y, ce n'est pas si simple.
Oui Amazon marge, mais on le sait bien que ce secteur d'activité fonctionne avec des pics et des creux. Il y a des périodes où oui.scnf reçoit beaucoup de requêtes (en journée en France et à l'approche des vacances) et d'autres où c'est le néant comme la nuit en France.
Donc pour gérer ces pics de charge, oui.sncf doit surdimensionner son infra. Ou renoncer à servir convenablement les clients durant ces pics (c'est un choix mais coûteux aussi). De plus il a besoin d'une armée d'admin sys capables de gérer une telle infra dans les règles de l'art, ce n'est pas si facile à trouver.
Amazon (ou un autre prestataire du genre) peut mutualiser les machines entre différents clients pour gérer les pics des différents clients sans trop surdimensionner l'ensemble. Donc on réduit les coûts en matériel, en énergie et en espace. De plus, de part leur métier avec AWS, ils ont les compétences en interne pour maintenir cette infra. C'est leur boulot et le feront probablement mieux que n'importe quelle équipe constituée par oui.sncf de manière adhoc.
Donc oui, j'insiste : chacun son métier, l'intégration verticale ça peut fonctionner mais ce n'est pas un absolu.
[^] # Re: Qu'à moitié étonné
Posté par MrBidon . Évalué à 9. Dernière modification le 10 décembre 2021 à 13:47.
L'argument pourri de la résilience et des pics de charges pour justifier le choix d'aller chez l'oncle SAM… Rien ne les empêche d'avoir des hébergements chez plusieurs cloud européens comme OVH, Hetzner ou Scaleway pour avoir de la résilience. Des loadbalanceurs, ça se met bien en place par chez nous aussi.
Une décision comme celle-ci est agaçante, car on est sur un choix classique de DSI d'entreprise publique qui migre par défaut vers un cloud US à la mode (on entend aussi souvent parler de Azure, AWS ou Google) suite à du lobying. J'avais fais une comparaison entre AWS et OVH on est 4 fois plus cher. Avec l'argent économisé, on peut largement payer de la R&D pour combler l'écart entre AWS et le cloud Européen.
[^] # Re: Qu'à moitié étonné
Posté par Renault (site web personnel) . Évalué à 4.
Je répondais à l'argument d'avoir tout en interne sous contrôle, je n'ai pas dit que Amazon était un meilleur choix que OVH, mais que Amazon était probablement un meilleur choix que de tout internaliser. Ce n'est pas pareil.
Je ne connais pas bien les acteurs pour me prononcer au delà de ce que j'ai dit.
[^] # Re: Qu'à moitié étonné
Posté par TuxMips . Évalué à 8.
Et le tout sans parler du fait que le Safe Harbour a été invalidé, que le Privacy Shield a aussi été invalidé et qu'à l'heure actuelle la base juridique pour opérer un tel transfert de données n'est pas sans risque !!! N'oublions pas non plus le Cloud Act et l'extra-territorialité du droit US (et me parlez pas de la localisation des serveurs en Europe …).
Prendre le train, cela va désormais me "coûter cher" :-(
[^] # Re: Qu'à moitié étonné
Posté par Pinaraf . Évalué à 4.
C'est étonnant, pourquoi l'hébergement est différent du développement ? Ils n'ont qu'à sous-traiter le développement à Atos, Capgemini ou n'importe quelle SSII.
Et au passage, y'a pas que le «cloud» et sa gestion de VMs comme solution. Tu peux passer par des tas d'intermédiaires qui te louent N baies et le réseau qui va bien. Ou tu peux louer des serveurs dédiés chez OVH, Scaleway ou autre. Ou tu peux prendre le «cloud privé» d'OVH ou autre, offres qui normalement te permettent d'ajouter des machines en quelques clics, mais où tu choisis encore comment tu gères tes VMs. Etc, etc…
[^] # Re: Qu'à moitié étonné
Posté par cg . Évalué à 2.
J'avoue que j'ai jamais trop compris pourquoi des entreprises préfèrent ce fonctionnement (pas trop cherché non plus). CAPEX vs OPEX si j'ai bien suivi le verbiage. Si quelqu'un a une résumé, ça intéresse.
[^] # Re: Qu'à moitié étonné
Posté par Maclag . Évalué à 5.
Capex: il faut sortir beaucoup de thune là maintenant tout de suite et amortir sur des années: on n'aime bas ça, parce que l'année de la dépense, les comptes ne seront pas jolis.
Opex: on étale la dépense sans faire aucune vague sur le budget annuel, du coup les années se ressemblent.
Maintenant, je ne sais pas de quel Capex on parle ici, je suis dans les semi-conducteurs, et c'est une industrie à gros Capex, qui finit par devenir récurrent quand on devient assez gros, d'où l'externalisation grandissante des procédés de fabrication vers des fondeurs toujours plus gros eux aussi (et on ne parle même pas encore de la course a la finesse de gravure).
[^] # Re: Qu'à moitié étonné
Posté par GG (site web personnel) . Évalué à 3. Dernière modification le 11 décembre 2021 à 18:52.
Certes, mais tu peux toujours faire une provision, avec étalement.
D'ailleurs, les grosses dépenses sont prises en comptes avec étalements, parce que ce sont des investissements.
Mais, c'est vrai qu'au niveau comptable, une facture de prestation, c'est noyé avec le reste, et donc pas d'amortissements.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Qu'à moitié étonné
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 11 décembre 2021 à 19:04.
Et c'est de la tva déductible de la tva collectée.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Qu'à moitié étonné
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 7.
La SNCF préfère héberger le datacenter de la ville de Paris, qui pourra stocker aussi les données de l'APHP, Paris Habitat ou Eaux de Paris … mais pas les données de la SNCF, c'est ballot …
# Le coup de pression qui vient
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 10 décembre 2021 à 11:43.
2024, le président américain appelle le président français:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le coup de pression qui vient
Posté par mahikeulbody . Évalué à 5. Dernière modification le 10 décembre 2021 à 13:18.
D'ici 2024 on aura un cloud souverain sur lequel tout le monde aura migré (ou pas).
[^] # Re: Le coup de pression qui vient
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10.
Souverain mais piloté par Microsoft ou Amazon non ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Le coup de pression qui vient
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
Oui sous vérins états-uniens.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le coup de pression qui vient
Posté par mahikeulbody . Évalué à 4. Dernière modification le 10 décembre 2021 à 18:44.
Non, cette étape-là, ça sera en 2026 après l'échec du projet "cloud souverain franco-européen" pour cause de mésentente entre les différents partenaires (qui se garderont néanmoins de rendre les sous des subventions publiques).
Ah, on me souffle dans l'oreillette qu'on serait déjà en 2026, en fait.
[^] # Re: Le coup de pression qui vient
Posté par barmic 🦦 . Évalué à 10.
Pour être précis non ce n'est pas piloté par des gafam. Le cloud souverain dont on entend parler depuis quelques mois, c'est des français qui prennent des machines américaines ou asiatiques, les installent sur le territoire français et font tourner dessus du logiciel américain (littéralement faire tourner azure etc).
Donc ça n'a de souverain que l'accès aux machines physiques. C'est une incompréhension totale de ce qu'est le logiciel, c'est un doigt d'honneur fait aux vrais acteurs français de cloud et bien sûr le contrôle américain reste totale (c'est probablement encore plus rentable pour Microsoft de louer ses logiciels sans avoir à s'emmerder avec la gestion des machines). Au final on leur donne de l'argent et des parts de marché (le lock in vient du logiciel) au lieu d'aider les acteurs souverain.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.