'This is an initial version of the software, developed solely for the purpose of demonstrating the business flow of the solution. It is not intended for production use, and does not yet include the full set of functional, security, or integration features required for a live deployment.'
mais je comprends bien que ça ne fait pas de clic et d'indignation que de lire la doc.
Pour le coup je pense que vu le sujet afin de valider le flow business tu peux éviter le monitoring & co, mais là la question est: est-ce qu'on peut avoir une version installable partout. Ce n'est pas après avoir validé ton flow tu tu pourras régler ça si tu dois revoir tes fondations.
Je pense qu'ici ce n'est donc pas un point auxiliaire qui a été relégué, mais quelque chose de fondamental, donc qui doit être dans le POC (ou alors j'ai pas bien compris le but du POC ce qui est totalement possible aussi, ou que le fait de pouvoir s'en passer est trivial, mais de ce que j'avais vu en publiant mes modestes app sur le store Android c'est pas si simple que ça).
Posté par Christophe .
Évalué à 8 (+9/-3).
Dernière modification le 28 juillet 2025 à 13:36.
Ne soyons pas naïfs non plus: une fois qu'une implémentation de POC sera faite, ce sera certainement la base pour l'implémentation définitive, avec un vaste copier-coller. Si les Google Play Services sont dans le POC, elles seront dans la version finale, c'est quasi certain.
Et puis, comme le dit le commentaire au dessus, les Google Play Services changent fondamentalement le "business flow" à démontrer. Il n'a donc rien à faire dans ce POC.
Ne soyons pas naïfs non plus: une fois qu'une implémentation de POC sera faite, ce sera certainement la base pour l'implémentation définitive, avec un vaste copier-coller. Si les Google Play Services sont dans le POC, elles seront dans la version finale, c'est quasi certain.
Le POC utilise Google Play Services (GPS) mais ça n'implique rien du tout pour la version finale ; la preuve c'est que la version finale sur iOS n'utilisera pas les GPS.
Et puis, comme le dit le commentaire au dessus, les Google Play Services changent fondamentalement le "business flow" à démontrer.
Je ne vois rien dans le commentaire en question qui démontre ça. De plus, ça m'étonnerait qu'on valide un business flow qui dépende de l'OS sous-jacent. Il y aurait donc un autre business flow sur iOS ? J'ai l'impression qu'on confond business flow et le technical flow qui l'implémente.
Alors, moi aussi je ne me fais guère d'illusion sur la disponibilité de ce truc sur d'autres plateformes que Android ou iOS mais je ne déduis pas ça du POC en question.
Pour moi le business flow c'est bien quand tu as un POC qui a toute tes contraintes business, en enlevant tout le reste.
Donc si tu as une brique qui est contraire à une de tes contraintes principales (genre l'indépendance avec les USA ici) tu n'as pas validé ton POC, seulement une partie.
Après ça dépends de ce qu'on mets derrière business flow. Mais si ton UI fonctionne mais qu'une de tes brique de base n'est pas bonne, perso je ne valide pas le poc à mon équipe et il retourne sur le métier, non sans les féliciter d'avoir déjà validé une partie, c'est pas rien (faut les deux à la fin quoi).
Dans les divers commentaires sur le sujet (je sais plus si c'est les autres bugs, HN, ou Lobste.rs), quelqu'un fait remarquer que l'appli des pays bas n'a pas ses restrictions, donc que c'est sans doute une compétence des pays, car la Commission n'a pas pas les pleins pouvoirs, loin de la. C'est assez clairement hors des 6 cas de l'article 3 du TFEU, donc ça implique les pays membres, et donc la présentation de "futur application de l'UE" me semble trompeuse.
Et il faut bien voir que les API de Google en question, c'est pas non plus un truc compliqué à rajouter, il y a à tout casser 30 lignes de code. Et il faut pas oublier que c'est pas open bar, la doc parle de 10000 par jour et par application, avec une demande pour avoir plus. En supposant 1% des gens en UE qui utilise l'appli par jour, c'est 330 fois plus que le défaut. Vu qu'en dessous, il y a "instance d'application", je suppose que c'est bien 10 000 par application (comprendre par clé d'api de l'application).
Des recherches sur le web parlent de limites à 200 000 appels d'API par dev et par jour comme limite en plus des 10k cités, donc j'imagine qu'il y a besoin d'une double augmentation de quota, et qu'à un moment, ça va plus être gratos (surtout si on parle de 300 fois la limite à minima).
Mais pire encore, vu qu'il y a des limites, et qu'il sera sans doute pas trop dur de trouver les clés d'API, il y a un risque assez évident de DoS, vu qu'il suffit de faire 10k (ou la limite) requêtes pour bloquer l'application.
Et je suis clairement pas le premier à y penser vu que j'ai trouvé 2 articles de blog sur des produits concurrents qui mettent ça en avant.
Posté par Voltairine .
Évalué à 3 (+1/-0).
Dernière modification le 28 juillet 2025 à 15:10.
Tu peux ajouter ceci :
« Consumers should also be able to access services online without having to use private platforms or unnecessarily sharing personal data. They will have full control of the data they share. »
Les consommateurs devraient également pouvoir accéder aux services en ligne sans utiliser de plate-forme privée et sans partager inutilement des données personnelles. Ils auront un contrôle total des données qu'ils partagent.
Vu le journal publié sur le sujet sans le recul nécessaire j'ai l'impression que cela va générer beaucoup de bruit pour pas grand chose…
Ça ressemble assez à un truc du genre "on essaie pour voir si ça passe". Il vaut mieux en effet alerter de possibles dérives plutôt que d'attendre qu'il soit trop tard.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Comme d'hab, personne lit le readme
Posté par Misc (site web personnel) . Évalué à 3 (+4/-4).
Le readme qui dit:
'This is an initial version of the software, developed solely for the purpose of demonstrating the business flow of the solution. It is not intended for production use, and does not yet include the full set of functional, security, or integration features required for a live deployment.'
mais je comprends bien que ça ne fait pas de clic et d'indignation que de lire la doc.
[^] # Re: Comme d'hab, personne lit le readme
Posté par Jean Gabes (site web personnel) . Évalué à 5 (+6/-3).
Pour le coup je pense que vu le sujet afin de valider le flow business tu peux éviter le monitoring & co, mais là la question est: est-ce qu'on peut avoir une version installable partout. Ce n'est pas après avoir validé ton flow tu tu pourras régler ça si tu dois revoir tes fondations.
Je pense qu'ici ce n'est donc pas un point auxiliaire qui a été relégué, mais quelque chose de fondamental, donc qui doit être dans le POC (ou alors j'ai pas bien compris le but du POC ce qui est totalement possible aussi, ou que le fait de pouvoir s'en passer est trivial, mais de ce que j'avais vu en publiant mes modestes app sur le store Android c'est pas si simple que ça).
[^] # Re: Comme d'hab, personne lit le readme
Posté par Christophe . Évalué à 8 (+9/-3). Dernière modification le 28 juillet 2025 à 13:36.
Ne soyons pas naïfs non plus: une fois qu'une implémentation de POC sera faite, ce sera certainement la base pour l'implémentation définitive, avec un vaste copier-coller. Si les Google Play Services sont dans le POC, elles seront dans la version finale, c'est quasi certain.
Et puis, comme le dit le commentaire au dessus, les Google Play Services changent fondamentalement le "business flow" à démontrer. Il n'a donc rien à faire dans ce POC.
[^] # Re: Comme d'hab, personne lit le readme
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Le POC utilise Google Play Services (GPS) mais ça n'implique rien du tout pour la version finale ; la preuve c'est que la version finale sur iOS n'utilisera pas les GPS.
Je ne vois rien dans le commentaire en question qui démontre ça. De plus, ça m'étonnerait qu'on valide un business flow qui dépende de l'OS sous-jacent. Il y aurait donc un autre business flow sur iOS ? J'ai l'impression qu'on confond business flow et le technical flow qui l'implémente.
Alors, moi aussi je ne me fais guère d'illusion sur la disponibilité de ce truc sur d'autres plateformes que Android ou iOS mais je ne déduis pas ça du POC en question.
[^] # Re: Comme d'hab, personne lit le readme
Posté par Jean Gabes (site web personnel) . Évalué à 1 (+0/-1).
Pour moi le business flow c'est bien quand tu as un POC qui a toute tes contraintes business, en enlevant tout le reste.
Donc si tu as une brique qui est contraire à une de tes contraintes principales (genre l'indépendance avec les USA ici) tu n'as pas validé ton POC, seulement une partie.
Après ça dépends de ce qu'on mets derrière business flow. Mais si ton UI fonctionne mais qu'une de tes brique de base n'est pas bonne, perso je ne valide pas le poc à mon équipe et il retourne sur le métier, non sans les féliciter d'avoir déjà validé une partie, c'est pas rien (faut les deux à la fin quoi).
[^] # Re: Comme d'hab, personne lit le readme
Posté par Misc (site web personnel) . Évalué à 5 (+2/-0).
Dans les divers commentaires sur le sujet (je sais plus si c'est les autres bugs, HN, ou Lobste.rs), quelqu'un fait remarquer que l'appli des pays bas n'a pas ses restrictions, donc que c'est sans doute une compétence des pays, car la Commission n'a pas pas les pleins pouvoirs, loin de la. C'est assez clairement hors des 6 cas de l'article 3 du TFEU, donc ça implique les pays membres, et donc la présentation de "futur application de l'UE" me semble trompeuse.
Et il faut bien voir que les API de Google en question, c'est pas non plus un truc compliqué à rajouter, il y a à tout casser 30 lignes de code. Et il faut pas oublier que c'est pas open bar, la doc parle de 10000 par jour et par application, avec une demande pour avoir plus. En supposant 1% des gens en UE qui utilise l'appli par jour, c'est 330 fois plus que le défaut. Vu qu'en dessous, il y a "instance d'application", je suppose que c'est bien 10 000 par application (comprendre par clé d'api de l'application).
Des recherches sur le web parlent de limites à 200 000 appels d'API par dev et par jour comme limite en plus des 10k cités, donc j'imagine qu'il y a besoin d'une double augmentation de quota, et qu'à un moment, ça va plus être gratos (surtout si on parle de 300 fois la limite à minima).
Mais pire encore, vu qu'il y a des limites, et qu'il sera sans doute pas trop dur de trouver les clés d'API, il y a un risque assez évident de DoS, vu qu'il suffit de faire 10k (ou la limite) requêtes pour bloquer l'application.
Et je suis clairement pas le premier à y penser vu que j'ai trouvé 2 articles de blog sur des produits concurrents qui mettent ça en avant.
[^] # Re: Comme d'hab, personne lit le readme
Posté par Voltairine . Évalué à 3 (+1/-0). Dernière modification le 28 juillet 2025 à 15:10.
Tu peux ajouter ceci :
Les consommateurs devraient également pouvoir accéder aux services en ligne sans utiliser de plate-forme privée et sans partager inutilement des données personnelles. Ils auront un contrôle total des données qu'ils partagent.
Vu le journal publié sur le sujet sans le recul nécessaire j'ai l'impression que cela va générer beaucoup de bruit pour pas grand chose…
[^] # Re: Comme d'hab, personne lit le readme
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+6/-2).
On dirait un gamin qui remplit son pistolet à eau avec un air coquin et te jure que c'est juste pour arroser les fleurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Comme d'hab, personne lit le readme
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+2/-2).
Ça ressemble assez à un truc du genre "on essaie pour voir si ça passe". Il vaut mieux en effet alerter de possibles dérives plutôt que d'attendre qu'il soit trop tard.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
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.