Penses-tu vraiment que d'un point de vue technique, il est possible de securiser les donnees d'une tel base ? Si tu as la moindre competence technique, tu vas te rendre compte tout seul du risque. Prends bien en consideration que cette base devra etre partage par des dizaines d'administration, des milliers de personnes (voir des millions) avec des droits d'acces fins pour chacun d'entre eux...
J'ai assez de compétences technique pour savoir que sur ce genre de base on ne fait travailler ... personne et que justement il n'y a pas d'acces fins à regler.
Tu as une bonne séries de criteres et de croisements à effectuer et tu exportes un résultat à chaque "client" (ici les administrations) avec seulement ce qu'il peut et à le droit de voir (c'est à dire nettement moins que ce qu'il a aujourd'hui). Et ainsi de suite où chaque adminsitration refait la meme manip pour ses différents services.
Je doute que quiconque sur ces bases aie besoin d'un update temps réel, un export régulier suffit tout à fait (un truc hebdomadaire voire mensuel me parait acceptable pour les impots par exemple).
Effectivement ce genre de base aura le probleme de la sécurité de la base centrale. Ceci dit c'est encore plus le cas aujourd'hui : chaque administration a sa gestion, avec sa base, pas toujours tres bien gardée d'ailleurs. Crois moi si base centrale il y a ils vont en prendre plus soin.
D'ailleurs même pas besoin de base centrale ... pourquoi ne pourraient t'ils pas faire des importations, croisement et exports à chaque fois ? même pas besoin de creer cette base centrale plus longtemps que le nécessite le traitement. Ca remplit relativement bien le probleme de sécurité.
Maintenant pour des raisons philosophiques, je n'ai pas envie d'etre fiche via un simple numero, car ce numero serait adopte d'office par les banques, les assurances, les societes de publicites, ...
Pourquoi ? raisons philosophiques d'accord mais lesquelles ?
Car tu es _déja_ un numéro (que ce n° soit composé de nom/prénom/adresse auquel est rattafé un nombre unique n° sociétaire, ou qu'il soit un numéro unique auquel est rataché nom/prénom/adresse je ne vois que peu de différences).
[^] # Re: Administration : l'identifiant unique recalé
Posté par Éric (site web personnel) . En réponse à la dépêche Administration : l'identifiant unique recalé. Évalué à 2.
J'ai assez de compétences technique pour savoir que sur ce genre de base on ne fait travailler ... personne et que justement il n'y a pas d'acces fins à regler.
Tu as une bonne séries de criteres et de croisements à effectuer et tu exportes un résultat à chaque "client" (ici les administrations) avec seulement ce qu'il peut et à le droit de voir (c'est à dire nettement moins que ce qu'il a aujourd'hui). Et ainsi de suite où chaque adminsitration refait la meme manip pour ses différents services.
Je doute que quiconque sur ces bases aie besoin d'un update temps réel, un export régulier suffit tout à fait (un truc hebdomadaire voire mensuel me parait acceptable pour les impots par exemple).
Effectivement ce genre de base aura le probleme de la sécurité de la base centrale. Ceci dit c'est encore plus le cas aujourd'hui : chaque administration a sa gestion, avec sa base, pas toujours tres bien gardée d'ailleurs. Crois moi si base centrale il y a ils vont en prendre plus soin.
D'ailleurs même pas besoin de base centrale ... pourquoi ne pourraient t'ils pas faire des importations, croisement et exports à chaque fois ? même pas besoin de creer cette base centrale plus longtemps que le nécessite le traitement. Ca remplit relativement bien le probleme de sécurité.
Maintenant pour des raisons philosophiques, je n'ai pas envie d'etre fiche via un simple numero, car ce numero serait adopte d'office par les banques, les assurances, les societes de publicites, ...
Pourquoi ? raisons philosophiques d'accord mais lesquelles ?
Car tu es _déja_ un numéro (que ce n° soit composé de nom/prénom/adresse auquel est rattafé un nombre unique n° sociétaire, ou qu'il soit un numéro unique auquel est rataché nom/prénom/adresse je ne vois que peu de différences).