Bon j'avoue, le titre est un peu provocateur. Mais bon, si cela ne remet pas vraiment en cause la sécurité, cela ouvre quand même une faille: Les services secrets américains auront tous le temps et le loisir de trouver une faille dans la sécurité de la messagerie "française"… Et ce sera facilité si la DGSE y a laissé une backdoor…
si cela ne remet pas vraiment en cause la sécurité, cela ouvre quand même une faille
Cette phrase n'a pas de sens, ouvrir une faille remet en cause la sécurité du point de vue étatique français du moins.
L'idée de passer à Ovid est de ne pas dépendre des USA, et en fait ça dépend : déjà la grosse faille hyper évidente est que le gouvernement américain peut mettre la France sur la même liste que l'Iran et bam plus d'Ovid du tout d'utilisable. Une faille à peine moins évidente est que le gouvernement américain peut lire tous les fichiers.
Et à propos de cette accès… "pas important" car c'est chiffré d'après Ovid. Ils balancent "La rupture technologique d’Olvid est de garantir la sécurité de ses utilisateurs via des mécanismes cryptographiques, qui n’ont pas de nationalité, sans avoir à faire confiance aux serveurs.", moi je veux bien les croire, mais faut qu'ils assument, ils me mettent à dispo toutes les données stockées sur AWS (il n'y a pas qui parle quand à qui, à défaut de savoir de quoi?) que je sois au même niveau que le gouvernement américain question données récupérables, je ne vois pas du tout ce que ça changerait pour eux de me laisser l'accès si ils ont confiance dans leur sécurité face au gouvernement américain.
Tant qu'ils ne me laissent pas accès aux données chiffrées qu'ont Amazon, il faut considérer Ovid comme à peine moins écoutable par les USA que WhatsApp (bon, là je trolle un peu, à priori leur logiciel client est open source, donc on peut mieux voir et recompiler, mais ça ne dit rien de ce que Ovid stocke chez les ricains comme info perso genre la taille du paquet que j'ai envoyé à telle date à telle personne).
mais ça ne dit rien de ce que Ovid stocke chez les ricains comme info perso genre la taille du paquet que j'ai envoyé à telle date à telle personne).
Il me semble que les métadonnées ne permettent pas d'identifier les personnes qui communiquent puisqu'il s'agit d'une clé générée localement et transmise "de la main à la main" entre elles. Donc même Olvid ne sait pas qui sait (sauf peut-être si on utilise leur annuaire comme c'est sans doute le cas en entreprise).
Hormis cette précision, je suis d'accord avec toi.
PS. J'aimerais savoir si Olvid est comparable à Jami avec en plus un stockage temporaire intermédiaire (AWS) pour gérer les cas où le destinataire n'est pas connecté au moment de l'envoi mais qu'ensuite, c'est du P2P comme Jami. Ou bien si c'est plutôt comparable à Whatsapp mais avec un code "anonyme" non connu de Olvid plutôt qu'un identifiant comme le téléphone ou l'adresse email mais qu'au final Olvid et AWS connaissent au moins les adresses IP concernées.
Posté par NicolasP .
Évalué à 10.
Dernière modification le 17 décembre 2023 à 21:49.
Il me semble que les métadonnées ne permettent pas d'identifier les personnes qui communiquent puisqu'il s'agit d'une clé générée localement et transmise "de la main à la main" entre elles. Donc même Olvid ne sait pas qui sait
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
si cela ne remet pas vraiment en cause la sécurité, cela ouvre quand même une faille
Je suis d'accord que la phrase est ambiguë, mais c'est volontaire. Je ne veux pas trop polémiquer mais en même temps je crois pas en la sécurité d'Olvid. Ce que je veux dire, c'est que ce n'est pas une faille de sécurité qui permettrait à n'importe qui d'écouter. Cependant c'est clair que la NSA à des moyen hors du commun et partant du principe qu'il existe toujours une faille : elle peut tout à fait trouver une faille qu'elle soit dans le protocole en lui même (Mais cela peut-être difficile à exploiter comme nécessiter un super-calculateur.) mais aussi et surtout une failles plus basique comme dans l'authentification des admins ou la version de l'OS…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Oui mais non… C'est la messagerie sécurisé mais elle n'est pas française et Open-Source. En france on est chauvin et puis dans l'administration, quand ça marche et c'est efficace on essaye de faire autrement jusqu'à l'échec…
Plus probablement. Je pense que Tchap est vraiment sécurisé, c'est bien pour les service secrets et le président, mais pour les agents de l'administration, il faut pouvoir les mettre en confiance et les espionner… Je doute qu'il n'y ait pas une backdoor pour la DGSE sur Olvid… Une backdoor qui serait du pain béni pour la NSA.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Nous avons donc fait le choix d’héberger ce serveur chez AWS car c’est là que nous avons trouvé la meilleure qualité de service, avec le moins d’effort à fournir de notre côté pour la maintenance et le passage à l’échelle de notre infrastructure.
L’argument de l’effort en moins à fournir est juste et difficilement attaquable. L’ennui c’est que le choix d’un prestataire d’hébergement européeen n’est même pas dans le cahier des charges.
L’argument de l’effort en moins à fournir est juste et difficilement attaquable.
Il est surtout difficilement défendable. Enfin moi je te fais un tunneling vers WatsApp et puis ce sera moins d'"effort en moins à fournir". Cette argument est indigne d'une messagerie d'Etat qui a quasiment un budget illimité.
Pourquoi alors avoir fait l'effort de faire leur propre protocole? Boh, on a pas fais les audits de sécurité, c'était trop d'effort.
Moins d'effort = Plus d'argent. C'est de la pure cupidité L'Etat met 1 milllion et il ne faut pas que ça coûte plus de 1 000 euros?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Cet argument pour moi est un argument que je trouve foireux, et ce n'est pas avec ce genre d'argument qu'on s'en sortira. Je m'explique ( Je ne sais pas si ce que j'ai écrit est clair car difficile à exprimer dans un "monologue" pour moi) :
Il y a un tas de boites qui développent leurs outils et services interne en fonction des use cases. En gros elles n'investiront pas de temps ni d'argent pour un produit ou service si elles n'ont pas de clients qui acceptent de payer pour les investissements à faire. Je ne parle pas de petites structures mais de grosses sociétés telles que les banques, assurances télécom.
Mais d'un autre côté, elles refusent ce mode de fonctionnement aux autres acteurs locaux. Elles s'attendent à ce que ces acteurs délivrent un service aussi performant que des entreprises qui le font depuis des années …. mais n'investissent pas pour que ces entreprises puissent le faire, donc ces entreprises ne peuvent pas mettre en place lesdits services. Elles préfèrent livrer leurs données et la disponibilité de leurs services à des boites étrangères, américaines pour la plupart - qui ne sont pas forcément toujours nos amis. En regardant les choses un peu de haut, j'ai l'impression qu'on fait avec l'IT, les données et les services numériques les mêmes erreurs que celles qu'on a faites avec l'industrie, que l'on a quasi entièrement sous-traîtée à la Chine ou à l'inde (avec les conséquences qu'on a connues lors de la crise covid par exemple).
Comme l'indiquait Zenitram plus haut, la confidentialité des données n'est pas le seul critère à prendre en considération : il y a risque de coupure de service en cas de désaccord entre la France et les US (je pense par exemple à l'invasion de l'Irak par les US lors de la seconde guerre du golf : la France pourrait-elle agir aujourd'hui comme elle l'a fait à l'époque ?).
Les initiatives de cloud souverain telles qu'elles ont été faites il y a quelques années, ou telles qu'on tente de le faire aujourd'hui ne marcheront jamais : on y a intégré des entreprises qui n'ont pas la culture pour le faire (Orange par exemple pour citer celui que je connais). Il faudrait un ou plusieurs acteurs qui partent de zéro (un peu comme l'a fait Musk avec Tesla: partir de presque zéro - et c'est ce que certains constructeurs automobiles on fait en créant des filiales pour pouvoir développer les voitures électriques) avec des entreprises potentiellement utilisatrices qui investissent dans cette structure pour que ça fonctionne, en coupant tout lien avec les entreprises historiques (si ce n'est avoir avec eux une relation client/fournisseur pour accéder aux infrastructures déjà en place).
Ils ne refusent pas ils attendent une solution qui n'existe tout simplement pas :
Il n’existe aujourd’hui pas d’offre SecNumCloud de type PaaS, car construire une offre de ce type à partir d’une IaaS représente un travail colossal. Plutôt que d’essayer de développer ce service nous-mêmes, il nous semble plus judicieux de profiter du savoir-faire des acteurs du cloud français en les laissant construire leur offre PaaS SecNumCloud à leur rythme.
Le problème c'est que ça ne risque pas d'arriver vu que l'écart se creuse de plus en plus !
Posté par Zenitram (site web personnel) .
Évalué à 10.
Dernière modification le 17 décembre 2023 à 16:41.
Faudrait qu'ils se décident, c'est important la sécurité du serveur ou pas? d'un côté ils disent que leur techno permet de stocker à la vue du gouvernement américain sans soucis, de l'autre ils faudrait des serveurs SecNumCloud pour se protéger des regards.
Est-ce que ça signifie donc que le gouvernement américain est acceptable? Faudrait le dire explicitement alors, bien préciser que la souveraineté est comprise comme américaine.
La, on a l'impression qu'ils veulent afficher une souveraineté française théorique tout en acceptant une souveraineté américaine en pratique.
Et ce sans compte qu'ils semblent découvrir que OVH pourrait leur apporter quelque chose si ils parlaient avec eux… Du coup, ils vont parler business souverain… Par messagerie privée même pas chiffrée avec stockage sur des serveurs américains dont un gouvernement peut avoir accès de manière 100% légale, même les serveurs SMTP même pas en SSL seraient plus sûrs vis à vis d'un gouvernement étranger (pas moins difficile, mais officiellement illégal ce qui est mieux que le légal de l'autre côté, c'est dire le niveau), quelle souveraineté!.
Ils ne refusent pas ils attendent une solution qui n'existe tout simplement pas :
Mais comment viendra-t-elle si personne ne paye pour l construire ? Si la situation était inversée, je suis convaincu que les entreprises US mettraient de l'argent pour développer une solution américaine. Pour moi, choisir des cloud providers étrangers, c'est avoir une vue à très court terme.
Aujourd'hui ils n'ont peut-être pas les moyens des clouds américains mais il ne faut pas oublier que ça n'a pas toujours été le cas. Ils avaient une très grosse longueur d'avance, quasiment 20 ans, pendant laquelle ils se sont peut-être un peu endormis sur leur lauriers. Le réveil est un peu difficile du coup !
Posté par Xanatos .
Évalué à 7.
Dernière modification le 17 décembre 2023 à 15:49.
La même raison que pour les projets de clouds souverains qui s’enchaînent; la gestion des données de santé; de l'éducation nationale ; le plafond de verre pour accéder aux marchés d’État : politique et connivences en haut lieu (coucou Dassault/Orange/Thalès/Safran)
# Trolesque
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 16 décembre 2023 à 23:37.
Bon j'avoue, le titre est un peu provocateur. Mais bon, si cela ne remet pas vraiment en cause la sécurité, cela ouvre quand même une faille: Les services secrets américains auront tous le temps et le loisir de trouver une faille dans la sécurité de la messagerie "française"… Et ce sera facilité si la DGSE y a laissé une backdoor…
Pour la référence : https://linuxfr.org/users/glandos/journaux/le-gouvernement-francais-pousse-vers-olvid-une-solution-de-messagerie-instantanee-francaise
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Trolesque
Posté par Zenitram (site web personnel) . Évalué à 10.
Cette phrase n'a pas de sens, ouvrir une faille remet en cause la sécurité du point de vue étatique français du moins.
L'idée de passer à Ovid est de ne pas dépendre des USA, et en fait ça dépend : déjà la grosse faille hyper évidente est que le gouvernement américain peut mettre la France sur la même liste que l'Iran et bam plus d'Ovid du tout d'utilisable. Une faille à peine moins évidente est que le gouvernement américain peut lire tous les fichiers.
Et à propos de cette accès… "pas important" car c'est chiffré d'après Ovid. Ils balancent "La rupture technologique d’Olvid est de garantir la sécurité de ses utilisateurs via des mécanismes cryptographiques, qui n’ont pas de nationalité, sans avoir à faire confiance aux serveurs.", moi je veux bien les croire, mais faut qu'ils assument, ils me mettent à dispo toutes les données stockées sur AWS (il n'y a pas qui parle quand à qui, à défaut de savoir de quoi?) que je sois au même niveau que le gouvernement américain question données récupérables, je ne vois pas du tout ce que ça changerait pour eux de me laisser l'accès si ils ont confiance dans leur sécurité face au gouvernement américain.
Tant qu'ils ne me laissent pas accès aux données chiffrées qu'ont Amazon, il faut considérer Ovid comme à peine moins écoutable par les USA que WhatsApp (bon, là je trolle un peu, à priori leur logiciel client est open source, donc on peut mieux voir et recompiler, mais ça ne dit rien de ce que Ovid stocke chez les ricains comme info perso genre la taille du paquet que j'ai envoyé à telle date à telle personne).
[^] # Re: Trolesque
Posté par mahikeulbody . Évalué à 7.
Il me semble que les métadonnées ne permettent pas d'identifier les personnes qui communiquent puisqu'il s'agit d'une clé générée localement et transmise "de la main à la main" entre elles. Donc même Olvid ne sait pas qui sait (sauf peut-être si on utilise leur annuaire comme c'est sans doute le cas en entreprise).
Hormis cette précision, je suis d'accord avec toi.
PS. J'aimerais savoir si Olvid est comparable à Jami avec en plus un stockage temporaire intermédiaire (AWS) pour gérer les cas où le destinataire n'est pas connecté au moment de l'envoi mais qu'ensuite, c'est du P2P comme Jami. Ou bien si c'est plutôt comparable à Whatsapp mais avec un code "anonyme" non connu de Olvid plutôt qu'un identifiant comme le téléphone ou l'adresse email mais qu'au final Olvid et AWS connaissent au moins les adresses IP concernées.
[^] # Re: Trolesque
Posté par NicolasP . Évalué à 10. Dernière modification le 17 décembre 2023 à 21:49.
La clef publique du destinataire est stockée sur le serveur. Si le modèle de menace est un geek qui a accès au serveur, on est d'accord : ça ne permet pas d'identifier les personnes qui communiquent. Mais si le modèle de menace c'est la vraie vie et la NSA qui essaye d'identifier les membres du gouvernement français qui communiquent, ça n'est pas très efficace (à moins que d'autres contre mesures ne soient implémentées).
Ils ont peut-être quelques dizaines de personnes à identifier. En notant les moments où ces personnes pianotent sur leurs téléphones, celles où elles ne le font pas et en corrélant avec ce qui passe sur le serveur, ça va aller vite pour identifier à qui est telle clef publique (très très vite pour ceux qui utilisent beaucoup le service, plus long pour ceux qui l'utilisent moins).
A noter que même sans ça, vu que la NSA a sûrement déjà une bonne idée de qui communique avec qui à quel moment/quelle fréquence, elle pourrait arriver à un bon taux de découverte.
[^] # Re: Trolesque
Posté par Xanatos . Évalué à 2.
Au sujet du stockage des clés de chiffrement.
A part ce document de 2021 je n'ai rien lu de plus récent.
Des sources ?
[^] # Re: Trolesque
Posté par NicolasP . Évalué à 2.
La FAQ : https://olvid.io/faq/serveur-et-open-source/.
[^] # Re: Trolesque
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Je suis d'accord que la phrase est ambiguë, mais c'est volontaire. Je ne veux pas trop polémiquer mais en même temps je crois pas en la sécurité d'Olvid. Ce que je veux dire, c'est que ce n'est pas une faille de sécurité qui permettrait à n'importe qui d'écouter. Cependant c'est clair que la NSA à des moyen hors du commun et partant du principe qu'il existe toujours une faille : elle peut tout à fait trouver une faille qu'elle soit dans le protocole en lui même (Mais cela peut-être difficile à exploiter comme nécessiter un super-calculateur.) mais aussi et surtout une failles plus basique comme dans l'authentification des admins ou la version de l'OS…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# tchap
Posté par sc-b303 . Évalué à 8. Dernière modification le 17 décembre 2023 à 09:01.
La messagerie officielle n'est elle pas censée être tchap depuis plusieurs années ?
https://tchap.beta.gouv.fr/
Et
https://www.numerique.gouv.fr/outils-agents/tchap-messagerie-instantanee-etat/
[^] # Re: tchap
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Oui mais non… C'est la messagerie sécurisé mais elle n'est pas française et Open-Source. En france on est chauvin et puis dans l'administration, quand ça marche et c'est efficace on essaye de faire autrement jusqu'à l'échec…
Plus probablement. Je pense que Tchap est vraiment sécurisé, c'est bien pour les service secrets et le président, mais pour les agents de l'administration, il faut pouvoir les mettre en confiance et les espionner… Je doute qu'il n'y ait pas une backdoor pour la DGSE sur Olvid… Une backdoor qui serait du pain béni pour la NSA.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Cocorico
Posté par moulator42 . Évalué à 7.
Je me demande ce qui les a empêché d'héberger ça chez OVH ou Online… à défaut des divers datacenters d'Etat.
[^] # Re: Cocorico
Posté par wilk . Évalué à 4.
https://olvid.io/faq/questions-d-actualite/#fonctionnement
[^] # Re: Cocorico
Posté par Sacha Trémoureux (site web personnel) . Évalué à 7.
L’argument de l’effort en moins à fournir est juste et difficilement attaquable. L’ennui c’est que le choix d’un prestataire d’hébergement européeen n’est même pas dans le cahier des charges.
[^] # Re: Cocorico
Posté par abriotde (site web personnel, Mastodon) . Évalué à 8.
Il est surtout difficilement défendable. Enfin moi je te fais un tunneling vers WatsApp et puis ce sera moins d'"effort en moins à fournir". Cette argument est indigne d'une messagerie d'Etat qui a quasiment un budget illimité.
Pourquoi alors avoir fait l'effort de faire leur propre protocole? Boh, on a pas fais les audits de sécurité, c'était trop d'effort.
Moins d'effort = Plus d'argent. C'est de la pure cupidité L'Etat met 1 milllion et il ne faut pas que ça coûte plus de 1 000 euros?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Cocorico
Posté par totof2000 . Évalué à 9.
Cet argument pour moi est un argument que je trouve foireux, et ce n'est pas avec ce genre d'argument qu'on s'en sortira. Je m'explique ( Je ne sais pas si ce que j'ai écrit est clair car difficile à exprimer dans un "monologue" pour moi) :
Il y a un tas de boites qui développent leurs outils et services interne en fonction des use cases. En gros elles n'investiront pas de temps ni d'argent pour un produit ou service si elles n'ont pas de clients qui acceptent de payer pour les investissements à faire. Je ne parle pas de petites structures mais de grosses sociétés telles que les banques, assurances télécom.
Mais d'un autre côté, elles refusent ce mode de fonctionnement aux autres acteurs locaux. Elles s'attendent à ce que ces acteurs délivrent un service aussi performant que des entreprises qui le font depuis des années …. mais n'investissent pas pour que ces entreprises puissent le faire, donc ces entreprises ne peuvent pas mettre en place lesdits services. Elles préfèrent livrer leurs données et la disponibilité de leurs services à des boites étrangères, américaines pour la plupart - qui ne sont pas forcément toujours nos amis. En regardant les choses un peu de haut, j'ai l'impression qu'on fait avec l'IT, les données et les services numériques les mêmes erreurs que celles qu'on a faites avec l'industrie, que l'on a quasi entièrement sous-traîtée à la Chine ou à l'inde (avec les conséquences qu'on a connues lors de la crise covid par exemple).
Comme l'indiquait Zenitram plus haut, la confidentialité des données n'est pas le seul critère à prendre en considération : il y a risque de coupure de service en cas de désaccord entre la France et les US (je pense par exemple à l'invasion de l'Irak par les US lors de la seconde guerre du golf : la France pourrait-elle agir aujourd'hui comme elle l'a fait à l'époque ?).
Les initiatives de cloud souverain telles qu'elles ont été faites il y a quelques années, ou telles qu'on tente de le faire aujourd'hui ne marcheront jamais : on y a intégré des entreprises qui n'ont pas la culture pour le faire (Orange par exemple pour citer celui que je connais). Il faudrait un ou plusieurs acteurs qui partent de zéro (un peu comme l'a fait Musk avec Tesla: partir de presque zéro - et c'est ce que certains constructeurs automobiles on fait en créant des filiales pour pouvoir développer les voitures électriques) avec des entreprises potentiellement utilisatrices qui investissent dans cette structure pour que ça fonctionne, en coupant tout lien avec les entreprises historiques (si ce n'est avoir avec eux une relation client/fournisseur pour accéder aux infrastructures déjà en place).
[^] # Re: Cocorico
Posté par wilk . Évalué à 1.
Ils ne refusent pas ils attendent une solution qui n'existe tout simplement pas :
Le problème c'est que ça ne risque pas d'arriver vu que l'écart se creuse de plus en plus !
[^] # Re: Cocorico
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 17 décembre 2023 à 16:41.
Faudrait qu'ils se décident, c'est important la sécurité du serveur ou pas? d'un côté ils disent que leur techno permet de stocker à la vue du gouvernement américain sans soucis, de l'autre ils faudrait des serveurs SecNumCloud pour se protéger des regards.
Est-ce que ça signifie donc que le gouvernement américain est acceptable? Faudrait le dire explicitement alors, bien préciser que la souveraineté est comprise comme américaine.
La, on a l'impression qu'ils veulent afficher une souveraineté française théorique tout en acceptant une souveraineté américaine en pratique.
Et ce sans compte qu'ils semblent découvrir que OVH pourrait leur apporter quelque chose si ils parlaient avec eux… Du coup, ils vont parler business souverain… Par messagerie privée même pas chiffrée avec stockage sur des serveurs américains dont un gouvernement peut avoir accès de manière 100% légale, même les serveurs SMTP même pas en SSL seraient plus sûrs vis à vis d'un gouvernement étranger (pas moins difficile, mais officiellement illégal ce qui est mieux que le légal de l'autre côté, c'est dire le niveau), quelle souveraineté!.
Chapeau quand même pour l'aplomb.
[^] # Re: Cocorico
Posté par totof2000 . Évalué à 6.
Mais comment viendra-t-elle si personne ne paye pour l construire ? Si la situation était inversée, je suis convaincu que les entreprises US mettraient de l'argent pour développer une solution américaine. Pour moi, choisir des cloud providers étrangers, c'est avoir une vue à très court terme.
[^] # Re: Cocorico
Posté par wilk . Évalué à 1.
Aujourd'hui ils n'ont peut-être pas les moyens des clouds américains mais il ne faut pas oublier que ça n'a pas toujours été le cas. Ils avaient une très grosse longueur d'avance, quasiment 20 ans, pendant laquelle ils se sont peut-être un peu endormis sur leur lauriers. Le réveil est un peu difficile du coup !
[^] # Re: Cocorico
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 18 décembre 2023 à 10:34.
Quand on veut gérer un service critique, déployer quelques vms devraient être une formalité…
Le PaaS c'est pour les noobs qui savent pas installer Debian [/mechant]
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Cocorico
Posté par Xanatos . Évalué à 7. Dernière modification le 17 décembre 2023 à 15:49.
La même raison que pour les projets de clouds souverains qui s’enchaînent; la gestion des données de santé; de l'éducation nationale ; le plafond de verre pour accéder aux marchés d’État : politique et connivences en haut lieu (coucou Dassault/Orange/Thalès/Safran)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.