En fait là on passe aux conflits potentiels entre droit moral et contraintes RGPD. Mais à mon avis c'est quelque chose à éclaircir. En y réfléchissant un peu, il semble que ce soit ici le droit moral qui s'exerce, au moins pour du code et/ou des séquences vidéos.
Celà dit si le repo GIT permet, via les commits d'associer un UID à une personne (qui aurait été anonymisé en supprimant ce lien par une procédure ad hoc par ailleurs), je pense que ça pose problème.
Quand j'essaie d'ouvrir un compte sur leur market, je ne le peux pas … Je suis censé cocher une case que je ne vois pas.
En plus je trouve qu'ils demandent beaucoup d'informations et chose qui m'a agacé", ils indiquent qu'ils utilisent des cookies, et que si on continue suir leur site c'est que ça ne nous dértange pas. Je ne pense pas que ce soit très RGPD …
Ils sont plus ou moins "encensés" de partout mais perso, quand je vois ça, poiur un outil qui est censé gérer des trucs qui potentiellement lui donne accès à plein d'éléments de la vie privée (caméra, etc …), le niveau de confiance redescend un max.
Tout à fait. En fait le RGPD étant un peu "jeune", je suis certain qu'on aura des cas ou la limite fixée empêche certaines choses qui sont plutôt légitime. Comme je te disais, si le but du traîtement des données personnelles c'est de protéger la vie privée des gens, il ne faudrait pas non plus tomber d'ans l'extrême ou pour protéger la vie privée des gens, tu en viens à ne pas conserver (attention, je ne parle pas de divulgation ais de conservation) des donnée qui relève non pas de vie privée, mais de vie "semi privée (vie en société). Après pour une fois que la directive est en faveur des individus plutôt qu'en faveur des (grands) groupes, je ne me plains pas …
Comme vous ne pouvez pas conserver indéfiniment les données personnelles dans vos fichiers et sauf si elle est précisée par un texte, une durée de conservation doit être définie en fonction de l'objectif poursuivi lors de la collecte de ces données. Une fois l'objectif atteint, ces informations doivent être archivées, supprimées ou anonymisées. C'est à vous de définir, selon la nature des données, de leur utilité et du but recherché, la durée de conservation des données. Prenez garde à ce qu'elle ne soit pas excessive par rapport aux raisons pour lesquelles vous les collecter.
=> ces informations doivent être archivées, supprimées ou anonymisées.
Si supprimer le lien entre un ID et une personne est suffisant pour anonymiser celle-ci, ce que je disais plus haut a du sens …
En terme de log, GIT ne donne accès qu'à l'historique des accès accordés (via les commits), et qui a accordé ces droits, ce qui est un peu différent.
Pour être plus précis, dans la solution que j'envisageais, GIT ne donne accès qu'à deux types de données :
- l'historique des accès accordés ( une photo des droits d'accès aux locaux par tous les employés à un instant T via les commits)
- qui a accordé ces droits
Si la deuxième partie est empêchée ar le RGPD, du coup on ne peux plus utiliser GIT en entreprise. Pour la première partie, de mon point de vie si ce n'est pas possibe, je trouve de mon point de vue que c'est un peu excessif, mais là encore il y a potentiellement des cas d'abus que je n'ai pas identifié.
est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale;
Avant otut j'ai conscience que ce que je veut dire est difficilement applicable à ce que je proposais dans ma solution basée sur GIT, mais :
Si tu crées un identifiant plus ou moins aléatoire (soit un hash, ou n'importe quoi), et que tu te réfères à cet "identifiant", mais qu'au bout de x années (définies par le législateur) tu "casses" le lien entre la personne et cet identifiant, à première vue, ça nbe devrait pas poser de problème, étant donné que la possibilité d'identifier la personne a disparu.
LA seule contrainte serait de savoir à un instant T quels snt les id qui ont été utilisés de ce qui ne l'ont pas été.
La question n'est pas d'avoir une excuse mais d'avoir un équilibre. Le but du RGPD est bien de protéger la vie privée des gens. Qu'on ne suive pas à la trace ce qu'une personne a fait dans l'entreprise pendant tout le temps qu'il y était est une bonne chose. Par contre (mais ce n'est que mon avis) qu'une entreprise ne puisse pas conserver un historique des personnes ayant travaillé pour elles, ainsi que leur fonctionnalité (sur laquelle se baserait leurs accès) me parait un peu exagéré. Après, y mettre des gardes-fou (du style déclaration à la CNIL des informations nécessaires à cet usage,pour que celle-ci anayse s'il y a abus me paraitrait un peu plus équilibré). Après il y a peut-être des abus potentiel que je ne vois pas, ais j'aimerais justement connaître ce type d'abus pour pouvoir comprendre le pourquoi de ce qui me paraît strict.
. Après est-ce que le RGPD est aussi strict que ça ? Est-ce qu'une déclaration à la CNIL pourrait permettre de conser ver ce genre d'infos ? Je ne sais pas …
Qu'appelle-t-on données personnelles ? C'est ça la question. Parce que si le but c'est de protéger la vie privée des salariés, le fait de savoir qu'un memere de l'entreprise a eu accès à celle-ci durant le temps qu'il était employén c'est oas de la vie privée, c'est de la vie d'entreprise.
Si c'est vrai, le RGPD va beaucoup troploin sur ce point (ou alors il a été mal défini …)
Tu ne conserves pas les logs d'accès dans GIT, mais juste qui a eu accès à quoi à un instant T dans ton entreprise (les permissions). Pour moi ça fait partier des données administratives..
Après tu peux peut être gérer ça en utilisant un hash plutôt que le nom de ton employé de telle façon que l'identification d'un employé qui n'est plus dans la boite ne puisse se faire que si la RH te communique son hash … Et pour savoir qui c'est tu interroges une API de ta RH qui t'indique qui est cette personne. Au bout d'un moment celle-ci te dit que la personne en question n'est plus dans la société et qu'il y a un procédure particulière si on a besoin d'avoir des infos …
Mais bon ….. Je serais surpris que RGPD ne permette pas à un employeur de conserver ce à quoi celui-ci a eu accès lorsqu'il était employé chez lui.
Sinon j'ai pensé à un autre truc …. Il y a peut être des contraintes (certifications pour que l'on puisse être assuré par exemple) qui font qu'une partie (hardware/module de comande) ne pourra pas être faite en mode DIY … C'est un aspect à contrôler (les systèmes d'ascenceur doivent répondre à certaines normes, au moins pour les cages, et toute l'infra physique, je ne sias pas si c'est le cas pour les systèmes/cartes de contrôle de montée/descente).
Sinon est-ce que tu peux préciser ton besoin ? Est-ce que tu cherches juste le logiciel qui serait chargé de gerer la base d'association utilisateurs=> badges pour transmettre les infos à un matériel déja existant (centrale) ou tu envisagerais quelque chose de plus complet qui gèrerait du matériel plus ou moins libre (firmware du matos) ?
L'accès à mon immeuble est géré par digik … donc je comprends un peu ce que tu veux mais pas a 100%. Est-ce que tu veux juste gérer les portes d'entrée, du batiment, ou gérer aussi des zones plus fines du batiment, avec éventuellement des portiques (style portiques à 3 branches ou portiques utilisé dans les systèmes de métro) ? A quel niveau es-tu prêt à descendre ?
le logiciel est connecté à la centrale via un bus rs485, et envoie les mises à jour des listes d'accès au fur et à mesure. Il reçoit aussi les logs via ce bus rs485.
Ok, la on parle des logs d'ouverture de porte … je n'avais pas compris ça comme ça … Si on a le protocole d'échange (RS485 ,c'est comme RS232 : ça définit les caractéristiques électriques de ligne, pas les messages échangés). Il faudrait que le protocole soit documenté par le constructeur de la centrale pour implémenter un échange. Si c'est pas chiffré on doit pouvoir relativement simplement sniffer le bus pour essayer de comprendre comment ça marche, mais comme tout reverse engineering, ça prend beaucoup de temps …
depuis le logiciel, il faut transférer la configuration sur un petit stockage flash, puis mettre cette mémoire flash dans chaque centrale pour importer les configs. Pour récupérer les logs, il faut aussi les exporter depuis la centrale pour les mettre sur un PC ensuite.
Là c'est pareil, il faut savoir comment sont organisées les données stockées sur le flash. Si c'est un support non standard, il faudra déjà comprendre comment on s'interface avec le flash, puis une fois que c'est fait, savoir comment les données sont organisées dessus. Si c'est du standard (Compact Flash, I2C, SPI, carte SD ou autre), seul le reverse engineering du contenu sera à faire si on a pas d'infos sur la façon dont il doit être organisé pour interagir avec.
Je me rend compte qu'une lib comme liblogicalaccess travaille à un niveau trop bas pour moi, puisqu'elle traite directement les événements des lecteurs de badge.
Oui elle ne fait ni plus ni moins … C'est un élément intéressant pour intégrer dans une solution plus globale (elle ne s'interface pas avec les portes). Mais elle pourrait servir à la phase d'association utilisateur-> badge (scan du badge pour l'associer à l'utilisateur lors de l'arrivée de celui-ci).
J'ai peut etre un truc chez moi qui me permetttrait de jouer avec cette lib (le truc qui permet de recharger son pass navigo depuis chez soi …). Je peux peut-être faire quelque sexpérimentations dessus.
Sinon en regardant j'ai l'impression que toutes ces solutions sont proprios, à des niveaux plus ou moins élevés :( J'ai cru voir (j'ai fait quelques recherches suite à ton post) quelque strucs plus ou moins modulaire, mais la documentation n'est as forcément en libre accès.
Perso c'est un truc sur lequel j'aimerais bien bosser. Sinon Ca peut faire l'objet d'un projet de fin d'année intéressant pour des élèves de bac STI Electronique (si ça se fait encore - moi j'étais en F2 et j'ai eu un projet de fin d'année à réaliser - une carte d'interface moteur pas à pas sur un ensemble qui servait à doser du café) ou pour des élèves de BTS …
Oui, je vois bien comment développer un système, et en effet git est tout vu pour garder les historiques, chouette idée.
Oui, tu délègues la gestion d'historique et de droits demodification à Git …
Je me rend compte qu'une lib comme liblogicalaccess travaille à un niveau trop bas pour moi, puisqu'elle traite directement les événements des lecteurs de badge.
Je regarde, ça peut être une piste intéressante. Par contre faut voir le matériel sous-jacent.
J'ai pensé à ça la vite fait (parce que ta description me faisaitpenser à Ansible), mais d'unb autre côté je me dis que GIT pour ce genre d'outil pourrait vraiment être une solution.
Branche Main (ou master) => l'état actue des droits. Une personne, ou un groupe de personnes chargé de merger les requetes sur cette branche.
Les demandes d'accès se font via pull request ou merge request par les personnes qui peuvent commiter.
Tu sais qui fait quoi, quand.
Voir s'il y a possibilité de mettre en place un frontend pour les demandes d'accès qui s'interfacerait à GIT.
transfert rapide et simple des listes d'accès aux centrales de contrôle des lecteurs et des portes.
Comment se fait ce transfert ( protocole d'échange, données attendues …).
Pour le reste, rien qui ne puisse se faire via script et base de données (sql, yaml, json, etc). Le tout dans un repo GIT pour avoir la trace des modification …
pouvoir définir des groupes de portes, qui vont être les niveaux d'accès
Tu pourrais définir ça un peu comme les inventaires Ansible.
pouvoir assigner une carte/un badge à une personne.
Pareil un truc basique clé/valeur en yaml
pouvoir associer cette carte/cette personne à un niveau d'accès.
Perso je définirais des groupes de personnes à qui je donnerais des accès à des groupes de portes. C'est plus simple à gérer. Ensuite tu fais les associatios par groupe (pareil, dans un yaml, de la même façon qu'ansible fait la relation entre les roles et les inventaires par les playbooks).
avoir accès aux journaux.
Si c'est les journaux des modifications, tu lègues ça à GIT?
pas d'accès à Internet.
Ca c ton firewall en amont qui doit gérer ça (avec un DHCP qui attribuerait automatiquement une IP à ta machne dédiée à ça). A moins que par "pas d'internet" tu veux dire "pas de réseau", mais c'est un peu compliqué si tu veux sauvegarder …
Ca c'est voir le verre a moitié vide. Le verre a moitié plein c'est que ça pourrait fair e des émules, que d'autres boites pourraient suivre le pas RiscV parce que ça signifierait que le marché sera demandeur (peu de boites ont la capacité de prendre des risques sur de nouvelles architectures CPU).
Les développement de RiscV peut être boosté. Ca ferait un sérieux concurrent à ARM - pour un cout de R&D moindre que de partir de zero (ça c ma vision du verre a moitié plein).
Et du coup AMD pourrait suivre le pas en achetant une boite qui développe du RiscV ou en produisant sa propre version.
Celà dit j'aurais préféré que ce soit une autre boite qu'Intel qui fasse ce rachat, parce que là, le risque pourraît être de vouloir tuer la concurrence dans l'oeuf, mais sauf erreur de ma part, sur ce créneau de CPU, Intel n'a pas vraiment d'offre, et si on y réfléchit d'un point de vue stratégique, ce rachat a du sens - ils ont une carte a jouer.
Perso j'aurais été plus méfiant si ça avait été MicroChip par exemple
J'espère par contre que les concepteurs du CPU ont bien verrouillé le fait que ce coeur restera libre.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Tu as tout compris mon raisonnement …
En fait là on passe aux conflits potentiels entre droit moral et contraintes RGPD. Mais à mon avis c'est quelque chose à éclaircir. En y réfléchissant un peu, il semble que ce soit ici le droit moral qui s'exerce, au moins pour du code et/ou des séquences vidéos.
Celà dit si le repo GIT permet, via les commits d'associer un UID à une personne (qui aurait été anonymisé en supprimant ce lien par une procédure ad hoc par ailleurs), je pense que ça pose problème.
U juriste dans la salle ?
# Ca doit être Jeedom le problème ...
Posté par totof2000 . En réponse au journal Linux et libre : retour 20 ans en arrière ?. Évalué à 4. Dernière modification le 13 juin 2021 à 17:22.
Quand j'essaie d'ouvrir un compte sur leur market, je ne le peux pas … Je suis censé cocher une case que je ne vois pas.
En plus je trouve qu'ils demandent beaucoup d'informations et chose qui m'a agacé", ils indiquent qu'ils utilisent des cookies, et que si on continue suir leur site c'est que ça ne nous dértange pas. Je ne pense pas que ce soit très RGPD …
Ils sont plus ou moins "encensés" de partout mais perso, quand je vois ça, poiur un outil qui est censé gérer des trucs qui potentiellement lui donne accès à plein d'éléments de la vie privée (caméra, etc …), le niveau de confiance redescend un max.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Tout à fait. En fait le RGPD étant un peu "jeune", je suis certain qu'on aura des cas ou la limite fixée empêche certaines choses qui sont plutôt légitime. Comme je te disais, si le but du traîtement des données personnelles c'est de protéger la vie privée des gens, il ne faudrait pas non plus tomber d'ans l'extrême ou pour protéger la vie privée des gens, tu en viens à ne pas conserver (attention, je ne parle pas de divulgation ais de conservation) des donnée qui relève non pas de vie privée, mais de vie "semi privée (vie en société). Après pour une fois que la directive est en faveur des individus plutôt qu'en faveur des (grands) groupes, je ne me plains pas …
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Et pourquoi trouves-tu ça pire ?
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
D'après la référence citée plus haut :
=> ces informations doivent être archivées, supprimées ou anonymisées.
Si supprimer le lien entre un ID et une personne est suffisant pour anonymiser celle-ci, ce que je disais plus haut a du sens …
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1. Dernière modification le 13 juin 2021 à 15:18.
Pour être plus précis, dans la solution que j'envisageais, GIT ne donne accès qu'à deux types de données :
- l'historique des accès accordés ( une photo des droits d'accès aux locaux par tous les employés à un instant T via les commits)
- qui a accordé ces droits
Si la deuxième partie est empêchée ar le RGPD, du coup on ne peux plus utiliser GIT en entreprise. Pour la première partie, de mon point de vie si ce n'est pas possibe, je trouve de mon point de vue que c'est un peu excessif, mais là encore il y a potentiellement des cas d'abus que je n'ai pas identifié.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1. Dernière modification le 13 juin 2021 à 15:13.
Non, c'est pas ce genre d'infos que je voulais mettre dans GIT. (j'avais mal compris ce que le PI entendait par "log).
En terme de log, GIT ne donne accès qu'à l'historique des accès accordés (via les commits), et qui a accordé ces droits, ce qui est un peu différent.
Je veux juste savoir que pendant qu'il était employé, tartempion avait les droits d'accès aux toilettes ce qui est différent.
En fait même ça ne ne veux as le savoir. C'est GIT qui garderait cette info.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Si je cite la phrase :
est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale;
Avant otut j'ai conscience que ce que je veut dire est difficilement applicable à ce que je proposais dans ma solution basée sur GIT, mais :
LA seule contrainte serait de savoir à un instant T quels snt les id qui ont été utilisés de ce qui ne l'ont pas été.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
La question n'est pas d'avoir une excuse mais d'avoir un équilibre. Le but du RGPD est bien de protéger la vie privée des gens. Qu'on ne suive pas à la trace ce qu'une personne a fait dans l'entreprise pendant tout le temps qu'il y était est une bonne chose. Par contre (mais ce n'est que mon avis) qu'une entreprise ne puisse pas conserver un historique des personnes ayant travaillé pour elles, ainsi que leur fonctionnalité (sur laquelle se baserait leurs accès) me parait un peu exagéré. Après, y mettre des gardes-fou (du style déclaration à la CNIL des informations nécessaires à cet usage,pour que celle-ci anayse s'il y a abus me paraitrait un peu plus équilibré). Après il y a peut-être des abus potentiel que je ne vois pas, ais j'aimerais justement connaître ce type d'abus pour pouvoir comprendre le pourquoi de ce qui me paraît strict.
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
. Après est-ce que le RGPD est aussi strict que ça ? Est-ce qu'une déclaration à la CNIL pourrait permettre de conser ver ce genre d'infos ? Je ne sais pas …
[^] # Re: durée de conservation des infos
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1. Dernière modification le 13 juin 2021 à 14:39.
Qu'appelle-t-on données personnelles ? C'est ça la question. Parce que si le but c'est de protéger la vie privée des salariés, le fait de savoir qu'un memere de l'entreprise a eu accès à celle-ci durant le temps qu'il était employén c'est oas de la vie privée, c'est de la vie d'entreprise.
Si c'est vrai, le RGPD va beaucoup troploin sur ce point (ou alors il a été mal défini …)
[^] # Re: ouverture de porte
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Tu ne conserves pas les logs d'accès dans GIT, mais juste qui a eu accès à quoi à un instant T dans ton entreprise (les permissions). Pour moi ça fait partier des données administratives..
Après tu peux peut être gérer ça en utilisant un hash plutôt que le nom de ton employé de telle façon que l'identification d'un employé qui n'est plus dans la boite ne puisse se faire que si la RH te communique son hash … Et pour savoir qui c'est tu interroges une API de ta RH qui t'indique qui est cette personne. Au bout d'un moment celle-ci te dit que la personne en question n'est plus dans la société et qu'il y a un procédure particulière si on a besoin d'avoir des infos …
Mais bon ….. Je serais surpris que RGPD ne permette pas à un employeur de conserver ce à quoi celui-ci a eu accès lorsqu'il était employé chez lui.
[^] # Re: ouverture de porte
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Pour un truc comme ça j'aurais plutôt utilisé Go/Rust … Langages plus modernes, avec fichiers sour GIT comme je l'ai écrit plus haut.
[^] # Find it ....
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 5.
Mais je sais pas si le module est libre ….
https://doc.jeedom.com/fr_FR/plugins/security/gestAccess/
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 2.
Sinon j'ai pensé à un autre truc …. Il y a peut être des contraintes (certifications pour que l'on puisse être assuré par exemple) qui font qu'une partie (hardware/module de comande) ne pourra pas être faite en mode DIY … C'est un aspect à contrôler (les systèmes d'ascenceur doivent répondre à certaines normes, au moins pour les cages, et toute l'infra physique, je ne sias pas si c'est le cas pour les systèmes/cartes de contrôle de montée/descente).
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 3.
Sinon est-ce que tu peux préciser ton besoin ? Est-ce que tu cherches juste le logiciel qui serait chargé de gerer la base d'association utilisateurs=> badges pour transmettre les infos à un matériel déja existant (centrale) ou tu envisagerais quelque chose de plus complet qui gèrerait du matériel plus ou moins libre (firmware du matos) ?
L'accès à mon immeuble est géré par digik … donc je comprends un peu ce que tu veux mais pas a 100%. Est-ce que tu veux juste gérer les portes d'entrée, du batiment, ou gérer aussi des zones plus fines du batiment, avec éventuellement des portiques (style portiques à 3 branches ou portiques utilisé dans les systèmes de métro) ? A quel niveau es-tu prêt à descendre ?
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 3.
Ok, la on parle des logs d'ouverture de porte … je n'avais pas compris ça comme ça … Si on a le protocole d'échange (RS485 ,c'est comme RS232 : ça définit les caractéristiques électriques de ligne, pas les messages échangés). Il faudrait que le protocole soit documenté par le constructeur de la centrale pour implémenter un échange. Si c'est pas chiffré on doit pouvoir relativement simplement sniffer le bus pour essayer de comprendre comment ça marche, mais comme tout reverse engineering, ça prend beaucoup de temps …
Là c'est pareil, il faut savoir comment sont organisées les données stockées sur le flash. Si c'est un support non standard, il faudra déjà comprendre comment on s'interface avec le flash, puis une fois que c'est fait, savoir comment les données sont organisées dessus. Si c'est du standard (Compact Flash, I2C, SPI, carte SD ou autre), seul le reverse engineering du contenu sera à faire si on a pas d'infos sur la façon dont il doit être organisé pour interagir avec.
Oui elle ne fait ni plus ni moins … C'est un élément intéressant pour intégrer dans une solution plus globale (elle ne s'interface pas avec les portes). Mais elle pourrait servir à la phase d'association utilisateur-> badge (scan du badge pour l'associer à l'utilisateur lors de l'arrivée de celui-ci).
J'ai peut etre un truc chez moi qui me permetttrait de jouer avec cette lib (le truc qui permet de recharger son pass navigo depuis chez soi …). Je peux peut-être faire quelque sexpérimentations dessus.
Sinon en regardant j'ai l'impression que toutes ces solutions sont proprios, à des niveaux plus ou moins élevés :( J'ai cru voir (j'ai fait quelques recherches suite à ton post) quelque strucs plus ou moins modulaire, mais la documentation n'est as forcément en libre accès.
Perso c'est un truc sur lequel j'aimerais bien bosser. Sinon Ca peut faire l'objet d'un projet de fin d'année intéressant pour des élèves de bac STI Electronique (si ça se fait encore - moi j'étais en F2 et j'ai eu un projet de fin d'année à réaliser - une carte d'interface moteur pas à pas sur un ensemble qui servait à doser du café) ou pour des élèves de BTS …
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Oui, tu délègues la gestion d'historique et de droits demodification à Git …
Je regarde, ça peut être une piste intéressante. Par contre faut voir le matériel sous-jacent.
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
Ca pourrait être fun de développer ce genre de truc …
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 1.
J'ai pensé à ça la vite fait (parce que ta description me faisaitpenser à Ansible), mais d'unb autre côté je me dis que GIT pour ce genre d'outil pourrait vraiment être une solution.
Branche Main (ou master) => l'état actue des droits. Une personne, ou un groupe de personnes chargé de merger les requetes sur cette branche.
Les demandes d'accès se font via pull request ou merge request par les personnes qui peuvent commiter.
Tu sais qui fait quoi, quand.
Voir s'il y a possibilité de mettre en place un frontend pour les demandes d'accès qui s'interfacerait à GIT.
# J'ai vu ça
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 6.
https://www.openconcerto.org/fr/badge.html
# Je crois que le coeur du problème c'est
Posté par totof2000 . En réponse au message Contrôle d'accès physique (genre vigik). Évalué à 2.
Comment se fait ce transfert ( protocole d'échange, données attendues …).
Pour le reste, rien qui ne puisse se faire via script et base de données (sql, yaml, json, etc). Le tout dans un repo GIT pour avoir la trace des modification …
Tu pourrais définir ça un peu comme les inventaires Ansible.
Pareil un truc basique clé/valeur en yaml
Perso je définirais des groupes de personnes à qui je donnerais des accès à des groupes de portes. C'est plus simple à gérer. Ensuite tu fais les associatios par groupe (pareil, dans un yaml, de la même façon qu'ansible fait la relation entre les roles et les inventaires par les playbooks).
Si c'est les journaux des modifications, tu lègues ça à GIT?
Ca c ton firewall en amont qui doit gérer ça (avec un DHCP qui attribuerait automatiquement une IP à ta machne dédiée à ça). A moins que par "pas d'internet" tu veux dire "pas de réseau", mais c'est un peu compliqué si tu veux sauvegarder …
[^] # Re: Puisque personne ne l'a fait..:
Posté par totof2000 . En réponse au message Algèbre de Bool, cherche cours/doc/mooc/tuto whatever. Évalué à 1.
Ah, moi c'était les télétubbies ..
# Si j'ai bien compris ...
Posté par totof2000 . En réponse au journal Boîte à outils pour GitLab CI : la suite. Évalué à 1. Dernière modification le 11 juin 2021 à 20:49.
Euh … Finalement non ,mon jeu de mots risque de ne pas plair.
[^] # Re: nooooon!!
Posté par totof2000 . En réponse au lien [Enfer et damnation] Intel Reportedly Interested In Acquiring RISC-V Firm SiFive - phoronix. Évalué à 1. Dernière modification le 11 juin 2021 à 10:17.
Ca c'est voir le verre a moitié vide. Le verre a moitié plein c'est que ça pourrait fair e des émules, que d'autres boites pourraient suivre le pas RiscV parce que ça signifierait que le marché sera demandeur (peu de boites ont la capacité de prendre des risques sur de nouvelles architectures CPU).
Les développement de RiscV peut être boosté. Ca ferait un sérieux concurrent à ARM - pour un cout de R&D moindre que de partir de zero (ça c ma vision du verre a moitié plein).
Et du coup AMD pourrait suivre le pas en achetant une boite qui développe du RiscV ou en produisant sa propre version.
Celà dit j'aurais préféré que ce soit une autre boite qu'Intel qui fasse ce rachat, parce que là, le risque pourraît être de vouloir tuer la concurrence dans l'oeuf, mais sauf erreur de ma part, sur ce créneau de CPU, Intel n'a pas vraiment d'offre, et si on y réfléchit d'un point de vue stratégique, ce rachat a du sens - ils ont une carte a jouer.
Perso j'aurais été plus méfiant si ça avait été MicroChip par exemple
J'espère par contre que les concepteurs du CPU ont bien verrouillé le fait que ce coeur restera libre.