Historique de la page

...

• Une non satisfaction du produit actuellement utilisé, mal ou peu intégré dans votre Système d'Information (c'est ce qui nous a amené à développer ESUP-SG, voir à ce propos sgc-v3.pdf).
• Une meilleure maîtrise du SGC, de votre projet, de votre carte (souveraineté).
• Une indépendance vis à vis d'un prestataire et d'un logiciel propriétaire, dont la pérennité ne peut être garantie (ESUP-SGC est un logiciel libre qui vous appartient sans restriction).
• Une meilleure intégration du SGC dans votre Système d'Information, avec des interactions fortes et synchrones 
  • avec vos briques du SI, source de données : 
    • authentification/identification shibboleth
    • annuaire supann/ldap
    • bases de données sql
  • avec les services de votre SI, consommateurs de la carte : 
    • CROUS/IZLY : via l' API CROUS - grâce à l'usage de cette API (en lieu et place de InfoCarteCROUS) ESUP-SGC vous y apporte une maitrise des échanges, une compréhension et possibilité de résoudre les problèmes de synchronisation/activation de comptes et carte Izly, ce en temps réel ; les avantages sont nombreux et qualitatifs pour l'usager final qui utilise les services CROUS/IZLY (étudiant, personnel, ...). Au quotidien, et au vu des retours des établissements utilisant d'autres SGC qu'ESUP-SGC, actuellement (17/11/2023) ce seul critère justifie le choix d'ESUP-SGC.
    • Contrôle d'accès : la synchronisation temps réel de vos cartes avec les contrôles d'accès que peut vous permettre de mettre en place ESUP-SGC renforce indéniablement la sécurité de vos accès.
    • Bibliothèques
    • Impression
    • Initiative de la Carte Etudiante Européenne (ESC) - voir la page de documentation de l'intégration du projet Carte étudiante européenne dans ESUP-SGC pour les détails très techniques opérationnels.
    • Outils institutionnels divers
• Une interface web dédiée à chacun, dont les utilisateurs finaux (étudiants, personnels, invités)
• Une possibilité d'utiliser le matériel que vous souhaitez, en terme d'impression notamment ; toute la chaine d'édition pouvant utiliser uniquement des protocoles standards (et pas les API/SDK des imprimantes, ce en faisant une édition en 2 temps ; impression puis encodage), cela vous évite les problèmes récurrents de compatibilité des imprimantes vis à vis des version d'OS, de fin de vie de modèles d'imprimantes, d’instabilité matériel ... notamment au cours du temps.
• Une possibilité d'utiliser aussi bien des imprimantes zebra que evolis pour l'édition en 1 seul temps ; et une possibilité d'ajouter le support pour un autre modèle/marque particulier d'imprimante via un développement spécifique.
• La possibilité de lancer des éditions de carte depuis un simple smartphone sur une imprimante à carte partagée pour un ensemble de personnels (voir Édition en 1 temps)
• Des raisons purement budgétaires : si l'installation demande de l'effort technique (et donc un coût RH en interne), les coûts d'entretien et fonctionnement sont minimes ; pas de coût de licence, d'installation, de mise à jour, prestations logicielles auprès d'un tiers ; possibilité d'acheter des imprimantes au meilleur prix (pas de vente liée) ; possibilité de conserver le même logiciel indéfiniment (logiciel libre → pas de droit d'usage sur un interval de temps fixe pouvant être à tout moment révoqué / non reconduit).
• ...

Un certain nombre de raisons peuvent a contrario vous pousser à faire un autre choix :

• Le logiciel que vous utilisez actuellement vous convient et vous en êtes satisfait.
• Vous utilisez un logiciel qui n'est pas juste un SGC mais un gestionnaire d'identités dont les fonctionnalités spécifiques vous sont précieuses (ESUP-SGC n'est pas un gestionnaire d'identités, c'est un SGC qui a vocation à s'intégrer dans un Système d'Information déjà établi).
• Vous n'avez pas les compétences et les moyens humains disponibles et motivés pour mettre en place un tel logiciel
• Vous ressentez le besoin d'avoir un prestataire qui vous accompagne de bout en bout pour assurer la mise en œuvre de votre projet, ce avec un logiciel maitrisé par le prestataire.
• Vous pensiez passer sur ESUP-SGC en lieu et place de votre solution actuelle pour réaliser des économies de prestation et de licence : vous n'envisagiez pas cependant de changer/modifier/améliorer votre organisation, les fonctionnalités proposées, etc.
• ...

Bref, le choix n'est pas évident, et en tant que simple communauté et développeurs d'ESUP-SGC, nous n'avons aucun intérêt à vous convaincre de passer à ESUP-SGC si vous n'avez tout simplement pas l'envie, la motivation, la volonté d'adhérer à ce projet ; au contraire même, on serait très embêtés (en plus d'être étonnés tout de même  ) qu'ESUP-SGC vous donne moins de satisfaction que votre ancienne solution !

De quel matériel ai-je besoin ?

En plus des applications web à installer sur un serveur, il vous faut pour éditer des cartes :

• des cartes Mifare DesfireEV1 ou EV2
• un PC sous linux ou windows (l'encodeur ne fonctionne actuellement pas sous MAC OS)
• une imprimante à carte plastique ps/pcl (exemples : evolis primacy, zebra zxp7, fargo, ...)
• une webcam
• un lecteur de carte pc/sc (exemple : Identiv UTrust 3700 F)

L'impression des cartes nécessite de faire deux passages de carte ?

Avant la version 2 d'esup-sgc, et contrairement aux autres Systèmes de Gestion de Cartes, ESUP-SGC ne permettait effectivement pas d'imprimer et encoder la carte en 1 seul passage dans une imprimante à cartes disposant d'un lecteur/encodeur NFC.
Dans ESUP-SGC, et avec le fonctionnement historique issu de sa version 1, une carte est d'abord imprimée par une imprimante à carte, puis celle-ci est encodée dans un second temps (voir à ce propos la vidéo ESUP-SGC - demande de carte, impression, encodage et activation).

C'est un choix qui a été fait dès l'étude préliminaire, en toute conscience, avant même la conception du SGC.
A ce sujet, voir le document "ESUP-SGC : UN SGC LIBRE", Juin 2017.

• Une volonté de suivre au mieux le RGPD.
• Une politique d'établissement visant à réduire l’empreinte environnementale du numérique public :
  • les applications esup-sgc et associées sont particulièrement peu gourmandes
  • esup-nfc-tag-droid permet d'utiliser ou réutiliser (recycler) sur la durée des téléphones Android datées (compatibilité avec des Android 5 ou supérieures)
  • l'usage de standard, en optant pour l'impression en 2 passes, vous permet d'utiliser n'importe quelle imprimante à carte, dont de très anciennes, de ne pas lier la durée de vie de l'imprimante à  la durée de vie d'un matériel nfc intégré à l'imprimante elle-même, etc.

→ en ce sens, et  dès  sa  conception,  ESUP-SGC  fait  sans  doute  figure  de  cas  d’école  du  Référentiel  Général d'Écoconception de Services Numériques (RGESN) interministériel de l’état.

• ...

Un certain nombre de raisons peuvent a contrario vous pousser à faire un autre choix :

• Le logiciel que vous utilisez actuellement vous convient et vous en êtes satisfait.
• Vous utilisez un logiciel qui n'est pas juste un SGC mais un gestionnaire d'identités dont les fonctionnalités spécifiques vous sont précieuses (ESUP-SGC n'est pas un gestionnaire d'identités, c'est un SGC qui a vocation à s'intégrer dans un Système d'Information déjà établi).
• Vous n'avez pas les compétences et les moyens humains disponibles et motivés pour mettre en place un tel logiciel
• Vous ressentez le besoin d'avoir un prestataire qui vous accompagne de bout en bout pour assurer la mise en œuvre de votre projet, ce avec un logiciel maitrisé par le prestataire.
• ...

En conclusion, gardez à l'esprit qu'en tant que communauté et développeurs d'ESUP-SGC, nous n'avons aucun intérêt à vous convaincre de passer à ESUP-SGC si vous n'avez tout simplement pas l'envie, la motivation, la volonté d'adhérer à ce projet ; on serait très embêtés (en plus d'être étonnés tout de même ) qu'ESUP-SGC vous donne moins de satisfaction que votre ancienne solution !

De quel matériel ai-je besoin ?

En plus des applications web à installer sur un serveur, il vous faut pour éditer des cartes :

• des cartes Mifare DesfireEV1 ou EV2
• un PC sous linux ou windows (l'encodeur ne fonctionne actuellement pas sous MAC OS)
• une imprimante à carte plastique ps/pcl (exemples : evolis primacy, zebra zxp7, fargo, ...)
• une webcam
• un lecteur de carte pc/sc (exemple : Identiv UTrust 3700 F)

L'impression des cartes nécessite de faire deux passages de carte ?

Avant la version 2 d'esup-sgc, et contrairement aux autres Systèmes de Gestion de Cartes, ESUP-SGC ne permettait effectivement pas d'imprimer et encoder la carte en 1 seul passage dans une imprimante à cartes disposant d'un lecteur/encodeur NFC.
Dans ESUP-SGC, et avec le fonctionnement historique issu de sa version 1, une carte est d'abord imprimée par une imprimante à carte, puis celle-ci est encodée dans un second temps (voir à ce propos la vidéo ESUP-SGC - demande de carte, impression, encodage et activation).

C'est un choix qui avait été fait dès l'étude préliminaire, en toute conscience, avant même la conception du SGC.
A ce sujet, voir le document "ESUP-SGC : UN SGC LIBRE", Juin 2017.

Pour les établissements utilisant des SGC propriétaires, la mise en oeuvre des API propriétaires des imprimantes à cartes peut en effet poser La mise en oeuvre des API propriétaires des imprimantes à cartes pose en effet quelques problèmes : instabilité des drivers, imprimante spécifique imposée, code/librairie non évolutif lié à un environnement logiciel donné, nombre de pannes/erreurs potentielles élevée, nombre de rejets élevé, code fermé, coûts plus élevés, maintenance plus compliquée, temps de mise en oeuvre et de manutention plus important à l'usage. Pour les SGC propriétaires du marché, ces difficultés de mise en oeuvre peuvent en partie être traitées par les prestataires/éditeurs au travers de différentes prestations : achat d'imprimantes spécifiques au travers du prestataire (vente liée), contrat de maintenance matérielle, contrat de maintenance logicielle, formation d'installation, dépannage ponctuelle, montée de version logicielle, migration de codes sur une nouvelle version d'imprimantes, etc. Ces prestations font partie intégrante du modèle économique et ne posent de fait pas de problème aux éditeurs. Pour un SGC libre, la situation est toute autre ; pour que le modèle de développement et de mutualisation autour du logiciel libre tienne, on minimise au maximum les problèmes côté des établissements pour faire en sorte que leurs installations fonctionnent avec un minimum de support (stabilité, autonomie, indépendance notamment matérielle), il en découle un certain nombre de choix très pragmatiques, notamment celui de fonctionner au maximum sur des standards. Ainsi pour l'impression des cartes on propose proposait par défaut de se baser uniquement sur ps/pcl et pour l'encodage on utilise pc/sc ; ce qui implique impliquait d'imprimer et d'encoder la carte en 2 actions bien distinctes.

...

Aussi, pour les établissements qui éditent une quantité conséquente de cartes à imprimer/encoder tous les ans (l'Université de Rouen Normandie qui a développé ESUP-SGC accueille 35.000 étudiants), en plus d'utiliser des imprimantes à cartes performantes pour l'impression (le fait de n'être pas lié à une API propriétaire spécifique permet de choisir l'imprimante que vous souhaitez), on propose peut proposer d'utiliser une imprimante (avec lecteur nfc permettant l'encodage) pour procéder à l'encodage dans un second temps en utilisant les possibilités de chargement et d'encodage de l'imprimante par lot.
Actuellement on propose un tel "robot d'encodage" via un code spécifique à l'imprimante zxp3 de zebra. Dans le cadre de l'utilisation d'un autre type d'imprimante pour mettre en place cet encodage par lot, il faudra(it) porter le code sur l'API propriétaire spécifique à l'image que ce qui a été fait pour la zxp3 : https://github.com/EsupPortail/esup-sgc-client/tree/univ-rouen-robot-zxp3

EnfinCependant, et depuis la version 2.0 d'esup-sgc financée en partie via l'Appel À Projets Services Numériques Aux Étudiants ESUP-SGC 2022/2023, esup-sgc est également capable d'éditer une carte en un seul passage .!

La réponse à cettequestion est donc maintenant non : à l'instar des SGC du marché, esup-sgc vous permet aujourd'hui d'éditer les cartes en imprimant et encodant dans le même temps chaque carte. et c'est maintenant cette possibilité que l'on met en avant, notre implémentation sur les métériels evolis comme zebra étant parfaitement stable et efficace.
esup-sgc garde néanmoins la possibilité d'éditer les cartes en 2 temps et conserve cette spécificité de pouvoir être indépendant de tout matériel car utilisable avec n'importe quelle imprimante du marché (matériel passé ou à venir).

...

Oui, une page dédiée à cette question est proposée sur ce WIKI.

Nous devons/voulons migrer d'un SGC vers un autre, quels sont les points d'attention à observer ?

Suivant la solution que vous utilisez, vous pouvez avoir un niveau de maîtrise plus ou moins élevé de votre système de gestion de cartes et donc finalement de vos cartes et de leur fonctionnement.

Suivant l'éventuel prestataire qui vous fournit (ou fournissait) la solution, celui-ci a pu vous conduire à des choix propres à sa (ou même ses) solution(s) en matière d'édition de cartes (SGC, imprimantes) mais aussi d'usage de la carte (contrôle d'accès, émargement, retrait en bibliohtèque, ...).

Les points d'attention à considérer peuvent de fait être nombreux, en voici quelques uns :  :

Est-ce qu'un usager doit forcément faire une demande via l'interface web d'ESUP-SGC pour que l'on puisse lui imprimer sa carte ?

Contrairement aux SGC du marché, ESUP-SGC propose en effet une interface web aux utilisateurs pour qu'ils puissent demander leur carte (en utilisant leur navigateur d'ordinateur ou même un téléphone permettant de se prendre en photo au travers d'esup-sgc), désactiver leur carte en cas de perte ou de vol, payer éventuellement un renouvellement, etc.

Cependant, ESUP-SGC permet aussi aux gestionnaires de demander une carte pour un utilisateur donné, avec prise de vue par webcam interposée.

Enfin ESUP-SGC  propose aussi une api simple pour initialiser les demandes de cartes par script ; voir a Q/R "Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?"
Des établissements ont ainsi par exemple fait le choix d'initier les demandes de carte des étudiants dès que le SI-Scol a connaissance de l'inscription de l'étudiant, en reprenant la photo demandée lors de l'inscription.

Dans tous les cas, notez simplement que l'utilisateur doit être 'connu' de votre SI pour qu'esup-sgc récupère les données depuis votre SI ; et il doit avoir ainsi un eppn (eduPersonPrincipalName) utilisé comme identifiant métier d'un utilisateur dans esup-sgc.

Nous devons/voulons migrer d'un SGC vers un autre, quels sont les points d'attention à observer ?

Suivant la solution que vous utilisez, vous pouvez avoir un niveau de maîtrise plus ou moins élevé de votre système de gestion de cartes et donc finalement de vos cartes et de leur fonctionnement.

Suivant l'éventuel prestataire qui vous fournit (ou fournissait) la solution, celui-ci a pu vous conduire à des choix propres à sa (ou même ses) solution(s) en matière d'édition de cartes (SGC, imprimantes) mais aussi d'usage de la carte (contrôle d'accès, émargement, retrait en bibliohtèque, ...).

Les points d'attention à considérer peuvent de fait être nombreux, en voici quelques uns :  :

• Est-ce que le SGC utilisée jusque là correspond uniquement à un Système de Gestion de Cartes ou des fonctionnalités de gestionnaire d'identités ont également été utilisées ?
  Présentées comme SGC, certaines solutions vous offrent en fait la possibilité de créer des comptes locaux non liés au reste de votre Système d'Information souvent dans le but de créer des cartes dites génériques (invités, ou autres) : ce type de fonctionnalités de gestionnaire d'identités tend à faire de votre SGC le coeur de votre SI et donc à le déstructurer.
  ESUP-SGC ne propose pas de création de carte non liée à un compte utilisateur ; même si celui-ci peut correspondre à une simple entrée dans une table SQL, l'utilisateur doit pré-exister.
  
  
• Est-ce que les cartes éditées proposent des applications DESFIRE sécurisées de contrôle d'accès propriétaires au prestataire ou est-ce que l'application DESFIRE est bien la propriété de l'établissement et peut être recodée par un nouveau SGC (et utilisée par différents contrôles d'accès) ?
  Le principe des cartes DESFIRE est d'héberger plusieurs applications desfire permettant d'y associer différents services/usages (quand on dit application desfire ; comme on dit application xml ; il faut le comprendre comme "une manière d'utiliser quelque chose dans un but particulier"). Si il est normal que l'application Desfire crous/izly soit à usage (et la propriété) de Est-ce que le SGC utilisée jusque là correspond uniquement à un Système de Gestion de Cartes ou des fonctionnalités de gestionnaire d'identités ont également été utilisées ?
  Présentées comme SGC, certaines solutions vous offrent en fait la possibilité de créer des comptes locaux non liés au reste de votre Système d'Information souvent dans le but de créer des cartes dites génériques (invités, ou autres) : ce type de fonctionnalités de gestionnaire d'identités tend à faire de votre SGC le coeur de votre SI et donc à le déstructurer.
  ESUP-SGC ne propose pas de création de carte non liée à un compte utilisateur ; même si celui-ci peut correspondre à une simple entrée dans une table SQL, l'utilisateur doit pré-exister.
  Est-ce que les cartes éditées proposent des applications DESFIRE sécurisées de contrôle d'accès propriétaires au prestataire ou est-ce que l'application DESFIRE est bien la propriété de l'établissement et peut être recodée par un nouveau SGC (et utilisée par différents contrôles d'accès) ?
  Le principe des cartes DESFIRE est d'héberger plusieurs applications desfire permettant d'y associer différents services/usages (quand on dit application desfire ; comme on dit application xml ; il faut le comprendre comme "une manière d'utiliser quelque chose dans un but particulier"). Si il est normal que l'application Desfire crous/izly soit à usage (et la propriété) de crous/izly même si elle est sur votre (vous, établissement) carte qui vous (établissement toujours) appartient, il ne semble pas normal que l'application Desfire dédiée à votre contrôle d'accès ne vous appartienne pas (état de fait constaté dans un certain nombre d'établissements).
  
  
• Est-ce que votre SGC actuel vous permet de récupérer les données permettant de réimporter vos cartes dans un nouveau SGC ?
  Voyez si/comment vous pouvez récupérer les données telles que mentionnées dans la page Importation de 'cartes' dans ESUP-SGC / Migration des données

...

Pour être complet, il faut noter ici que le trigger appelé lors de la suppression d'un 'fichier' (d'une photo ici surtout) n'est pas appelé en supprimant/recréant la base aussi directement. De fait les blobs (lo postgresql pour large object) correspondants aux fichiers/photos stockés en base ne sont en fait pas supprimés de la base postgresql et se retrouvent 'orphelins' car plus référencés dans la base esup-sgc qui a été réinitialisée.
Ils "trainent" donc dans la base postgresql et ne dérangent pas le moins du monde, à part qu'ils utilisent de la place ...
Aussi ici pour 'nettoyer' la base et supprimer effectivement ces blobs, on peut alors utiliser l'utilitaire vacuumlo sur la base (juste après avoir relancé esup-sgc avec create donc) :
postgres@debian-i7:~$ vacuumlo esupsgcPlus d'info ici :
https://www.postgresql.org/docs/9.3/static/vacuumlo.htmlla base postgresql et se retrouvent 'orphelins' car plus référencés dans la base esup-sgc qui a été réinitialisée.
Ils "trainent" donc dans la base postgresql et ne dérangent pas le moins du monde, à part qu'ils utilisent de la place ...
Aussi ici pour 'nettoyer' la base et supprimer effectivement ces blobs, on peut alors utiliser l'utilitaire vacuumlo sur la base (juste après avoir relancé esup-sgc avec create donc) :
postgres@debian-i7:~$ vacuumlo esupsgc

Plus d'info ici :
https://www.postgresql.org/docs/9.3/static/vacuumlo.html

ESUP-SGC propose t'il un outil de trombinoscope ?

ESUP-SGC ne propose pas un tel module, mais son interfaçage peut se prêter à un développement rapide au besoin ; voir la question "comment récupérer les photos par script".

ESUP-MDW propose par contre un tel module et celui-ci permet nativement et par simple configuration (prévu à partir de la prochaine version d'esup-mdw → > 1.6.29) de reprendre les photos d'ESUP-SGC (via l'API REST également).

Comment configurer ESUP-MDW pour que les photos des étudiants proviennent d'ESUP-SGC ?

(prévu à partir de la prochaine version d'esup-mdw → > 1.6.29)

Il suffit de configurer le context.xml  ainsi :

<Parameter name="serveurphoto.implementation" value="photoEsupSgc" />
<Parameter name="param.esupsgc.urlphoto" value="https://esup-sgc.mon-univ.fr/wsrest/photo/%s/restrictedPhoto"/>

L'URL en restrictedPhoto permet côté esup-sgc de prendre en compte l'acceptation par l'étudiant de la diffusion de sa photo, suivant l'usage et les spécificités rgpd, l'établissement peut aussi ne pas prendre en compte cela en mettant simplement en url
https://esup-sgc.mon-univ.fr/wsrest/photo/%s/photo

A noter que %s est remplacé par l'eppn de l'étudiant récupéré du ldap (le ldap doit donc proposer cet attribut).

Côté esup-sgc, le contrôle d'accès au web-service des photos se fait via la propriété de accessRestrictionWSRestPhoto de security.properties où on propose par défaut de lister les IPs via des expressions type hasIpAddress('127.0.0.1') or hasIpAddress('0:0:0:0:0:0:0:1') or ...

Comment récupérer les photos par script ?

...