bloc-notes public de Marc Auer

paru dans PhiliMag nᵒ 35 (juin 2023)

---

Bonjour Florent, pouvez-vous vous présenter en quelques lignes ?

Bonjour, je suis Florent Coupeau, Directeur de Nuts! Publishing. Notre société est un petit éditeur breton tout au bout du continent près de l’océan et voisins de Bombyx que je salue ici. Avec mes collègues, on essaye de mettre notre passion et nos idées (après quelques Breizh cola ou Telenn Du pour les connaisseurs) au service des jeux qu’on publie. Cette présentation rapide ne serait pas complète sans mentionner l’apport de nos copains et/ou indépendants qui pour moi font partie de l’esprit de cette équipe.

Dans quel contexte la maison d’édition Nuts! Publishing a-t-elle été créée ? Quels étaient vos envies et vos objectifs ?

À l’origine, Nuts! Publishing est une société française de création et d’édition de jeux fondée en 2011 par 4 passionnés d’histoire et de jeux de simulation. À l’époque, les jeux édités étaient exclusivement des wargames de notre création ou de copains comme Phantom Fury ou Urban Operations. Suite à mon rachat de la société en 2018, nous avons étendu notre catalogue aux jeux de plateau. La première localisation a été One Deck Dungeon et notre première création de jeu de plateau Mini Rogue. Nous n’avions aucun objectif à part celui de publier des jeux qui nous plaisaient et qui apportent dans la mesure du possible un petit truc différent. One Deck Dungeon a un placement de cartes très intéressant, Auztralia mélange affrontement, ressources et placement de rails (et en plus c’est du Martin Wallace), Palm Island se joue dans la paume de la main, La Guerre de l’Anneau est une guerre épique dans le monde de Tolkien.

Quel est votre ligne éditoriale ? Avez-vous une spécificité ?

Notre ligne éditoriale est assez diversifiée même si certaines spécificités ressortent régulièrement (des boîtes à taille réduite mais assez pleines, des modes solo, des thèmes assez forts, etc.). Nous fonctionnons énormément au coup de cœur et nous possédons plusieurs gammes : les wargames (qui regroupent des jeux comme This War Without an Enemy mais aussi des « warteaux », une forme de fusion entre les wargames et les jeux de plateau, qui donne des jeux rapides, historiques, immersifs et fun, comme Saigon 75), une gamme pour familles et initiés (qui regroupe notamment des jeux coopératifs comme Sub Terra 2) ainsi qu'une gamme plus familiale encore (même si pour le moment nous ne publions pas plus d’un jeu familial par an).

De temps en temps, nous éditons aussi des serious games, des jeux pour les entreprises ou issus d’entreprises. Le dernier en date s’appelle Duel Tactique pour l’École de Guerre pour leur formation interne.

Pouvez-vous nous parler de vos jeux à venir ?

Bien sûr, avec grand plaisir. Voici quelques jeux que l’on a déjà annoncés ou qui sont actuellement en phase de développement chez nous :

• Résistance, un jeu solo simple, rapide, et magnifiquement illustré par Albert Monteys, mais exigeant. Il est attendu en boutiques courant juin.

• La Guerre de l'Anneau, le jeu de cartes, qui reprend l’aventure et le côté épique du jeu de plateau en le raccourcissant et qui est sorti le 19 mai.

• Diluvium, un 4X jouable de 2 à 4 joueurs, ou en campagne solo, où l’on explore les mers en s’affrontant pour faire à nouveau rayonner son empire et qui se joue en moins de 15 minutes par joueur. Il est créé par Antoni Guillen et illustré par Maud Chalmel et sortira au mois d’août de cette année.

Nous devrions également lancer à la fin du mois de juin une campagne de financement participatif sur Kickstarter pour MOOGH, un jeu de programmation et de dés, jouable de 1 à 4 joueurs, dans lequel des hommes préhistoriques s'affrontent pour prendre le contrôle de la tribu en chassant des bêtes gigantesques. Le jeu est créé et illustré par Niklas Hook.

de Douglas Adams (traduit par Michel Pagel)

Extrait d’un discours impromptu prononcé par Douglas Adams à Digital Biota 2, Cambridge, septembre 1998. Discours complet en anglais disponible à cette adresse : http://www.biota.org/people/douglasadams/index.html (obsolète ; voir archive).

Traduit de l’anglais par Michel Pagel en France et publié chez Gallimard, collection Folio SF, ISBN 2-07-030210-5. L’extrait court de la page 214 à 217.

Reproduit ici sans l’autorisation ni des ayant-droit de l’auteur, ni du traducteur ni de l’éditeur. Le titre a été rajouté, il n’a été choisi par aucune de ces 3 parties.

---

D’où vient l’idée de Dieu ? Notre point de vue est, à mon sens, faussé sur nombre de sujets mais tentons cependant de savoir d’où il vient. Prenez l’homme des origines. Comme toutes les autres c’est une créature évoluée, et il se retrouve dans un monde qu’il s’approprie peu à peu ; il commence à fabriquer des outils dont il se sert pour modifier son environnement, et il les fabrique bel et bien dans ce but précis. Pour donner un exemple de la manière dont il fonctionne par rapport à d’autres animaux, considérez la spéciation qui, d’après ce que nous savons, intervient lorsqu’un petit groupe se voit séparé du reste de la harde à l’occasion d’un plissement géologique, d’une surpopulation, d’une pénurie de nourriture ou de quoi que ce soit d’autre, et se retrouve dans un environnement différent, avec des règles différentes. Considérons un exemple très simple : un groupe d’animaux débarque dans un milieu bien plus froid que celui dont il a l’habitude. Au bout de quelques générations, les gênes qui déterminent une fourrure plus épaisse passent au premier plan et nous constatons que la fourrure des individus a effectivement épaissi. L’homme des origines, fabricant d’outils, n’a nul besoin d’un tel phénomène : il peut habiter des milieux d’une extraordinaire diversité, de la toundra au désert de Gobi — il se débrouille même pour vivre à New York, nom d’un chien ! —, car lorsqu’il arrive dans un environnement nouveau, il ne lui est pas nécessaire d’attendre plusieurs générations : dans un milieu plus froid, pour reprendre notre exemple, il lui suffit de voir un animal possesseur des gênes déterminant une épaisse fourrure pour se dire : « Sa fourrure, je vais la lui piquer. » Les outils nous autorisent un mode de pensée intentionnel, nous permettent de créer et d’accomplir des choses afin de façonner le monde à notre convenance. Imaginez maintenant l’homme des origines regardant autour de lui à la fin d’une heureuse journée passée à fabriquer des outils. Il observe un monde qui lui plaît énormément : derrière lui, des montagnes avec des cavernes — les cavernes, c’est génial, parce qu’on peut s’y cacher, elles protègent de la pluie et des ours ; devant lui, la forêt — remplie de fruits, de baies et d’une pléthore d’aliments délicieux ; non loin de là, une rivière — l’eau est délicieuse à boire, on peut en faire énormément de choses et même y naviguer avec un bateau ; là, voici le cousin Ug, qui a attrapé un mammouth — c’est génial, les mammouths : on peut les manger, se tailler des habits avec leur peau et utiliser leurs os pour fabriquer des armes qui permettent de chasser d’autres mammouths. C’est donc un monde absolument super, fabuleux. Et quand notre homme prend le temps de réfléchir, il se dit : « Ma foi, je vis dans un monde bien intéressant », puis il se pose une question perfide, fallacieuse, dépourvue de sens, mais qui lui vient en raison de sa nature, du genre d’être qu’en a fait l’évolution — un être qui a survécu parce qu’il raisonne de cette manière-là. L’homme, l’artisan, contemple donc son univers et se demande : « Et ça, qui est-ce qui l’a fabriqué ? » Vous voyez à quel point cette question est perfide ? « Étant donné que je connais une seule catégorie d’êtres à savoir fabriquer des choses, poursuit-il en lui-même, celui qui a fait ça doit être un genre de moi bien plus gros, bien plus puissant et nécessairement invisible. Et comme je suis l’élément fort du couple, celui qui se tape tout le gros œuvre, c’est sans doute un mâle. » Et paf ! On se retrouve avec le concept de Dieu. Ensuite, comme nous autres fabriquons des objets dans l’intention de les utiliser, l’homme des origines se demande : « S’il l’a fait, pourquoi est-ce qu’il l’a fait ? » Et c’est là que le piège se referme : « Ce monde me convient très bien. Il y a là toutes les choses qui me soutiennent, qui me nourrissent et me protègent, oui, décidément, ce monde me convient très bien. » Et notre homme en arrive à l’inévitable conclusion que le créateur dudit monde l’a créé pour lui.

C’est un peu comme d’imaginer une flaque s’éveillant un matin et se disant : « Oh, mais c’est un monde intéressant, ça — un trou intéressant —, et il me convient très bien, non ? En fait, il me convient parfaitement. Quelqu’un doit l’avoir fabriqué pour moi ! » C’est une idée extrêmement forte, au point qu’alors même qu’elle s’évapore, à mesure que le soleil monte dans le ciel et que l’air se réchauffe, la flaque s’accroche toujours à la conviction que tout va bien, parce que ce monde est fait pour l’accueillir, qu’il a été bâti pour l’accueillir ; sa disparition la prend donc un peu par surprise. Voilà peut-être une chose qu’il serait bon de surveiller. Nous savons tous que, un jour, l’univers trouvera son terme, et qu’un autre jour, nettement plus proche mais pas tout à fait imminent non plus, le soleil explosera. Nous pensons avoir tout le temps de nous en préoccuper, mais c’est là une réflexion très dangereuse. Il suffit de voir ce qui est censé se produire le 1er janvier 2000 — et n’essayons pas de dire que personne ne nous a prévenus que le siècle finirait par s’achever ! Si nous voulons survivre à long terme, nous devons considérer notre nature et les raisons de notre présence ici-bas dans une perspective un peu plus large.

Délibération n° 2020-049 du 23 avril 2020 portant avis sur un cahier des charges pour la certification des services de coffre-fort numérique (demande d’avis n° 20003671)

La Commission nationale de l'informatique et des libertés,

Saisie par l’Agence nationale de sécurité des systèmes d’information (ANSSI) d’un cahier des charges pour la certification des services de coffre-fort numérique ;

Vu la convention n° 108 du Conseil de l’Europe pour la protection des personnes à l’égard du traitement automatisé des données à caractère personnel ;

Vu le règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE ;

Vu le code des postes et des communications électroniques, notamment son article L. 103 ;

Vu la loi n° 78-17 du 6 janvier 1978 modifiée relative à l’informatique, aux fichiers et aux libertés ;

Vu le décret n° 2018-418 du 30 mai 2018 relatif aux modalités de mise en œuvre du service de coffre-fort numérique ;

Vu le décret n° 2018-853 du 5 octobre 2018 relatif aux conditions de récupération des documents et données stockés par un service de coffre-fort numérique ;

Vu le décret n° 2019-536 du 29 mai 2019 modifié pris pour l’application de la loi n° 78- 17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés ;

Vu la délibération n° 2013-270 du 19 septembre 2013 portant recommandation relative aux services dits de coffre-fort numérique ou électronique destinés aux particuliers ;

Vu la délibération n° 2018-102 du 15 mars 2018 portant abrogation des référentiels de labellisation ;

Sur la proposition de M. François PELLEGRINI, commissaire, et après avoir entendu les observations de Mme Nacima BELKACEM, commissaire du Gouvernement,

Émet l’avis suivant :

A titre liminaire, la Commission rappelle que le cadre juridique applicable aux services de coffre-fort numérique a été créé par la loi n° 2016-1321 du 7 octobre 2016 pour une République numérique. Le I de l’article 87 de la loi précitée, codifié à ce jour à l’article L. 103 du code des postes et des communications électroniques (CPCE), prévoit ainsi les caractéristiques nécessaires pour qualifier un service de coffre-fort numérique et la possibilité pour un service de coffre-fort numérique de bénéficier

d’une certification par l’Etat. Il est prévu que les modalités de certification des services de coffre-fort numérique soient définies par un décret en Conseil d’Etat pris après avis de la Commission conformément à l’article L. 103 du CPCE, lequel fait l’objet d’un avis distinct.

Elle relève que le cahier des charges qui lui est soumis pour avis fixe les exigences de sécurité que doit remplir un service de coffre-fort numérique pour bénéficier d’une certification par l’ANSSI. La Commission rappelle que le fournisseur d’un service de coffre-fort numérique devra également s’assurer de sa conformité à la réglementation relative à la protection des données à caractère personnel.

Elle rappelle également qu’elle s’est prononcée à plusieurs reprises sur les services de coffre-fort numérique, et ce dès 2013, en adoptant une recommandation relative aux services dits de coffre-fort numérique ou électronique destinés aux particuliers (délibération n° 2013-270 du 19 septembre 2013) et dans un avis sur deux projets de décrets portant application de l’article 87 de la loi n° 2016-1321 du 7 octobre 2016 pour une République numérique relatif au service de coffre-fort numérique (délibération n° 2017-178 du 1er juin 2017).

Ces éléments généraux rappelés, le cahier des charges appelle les observations suivantes de la part de la Commission :

En premier lieu, la Commission rappelle que son activité de labellisation a pris fin avec l’entrée en application du règlement européen sur la protection des données à caractère personnel susvisé et que le référentiel pour la délivrance de labels en matière de services de coffre-fort numérique, adopté par la délibération n° 2014-017 du 23 janvier 2014, a été abrogé par la délibération n° 2018-102 susvisée. Dans ce contexte, elle demande dès lors que le cahier des charges, notamment son annexe 2, soit mis à jour au regard de cette évolution. La Commission rappelle à cet égard que la délibération n° 2013-270 du 19 septembre 2013 portant recommandation relative aux services de coffre-fort numérique demeure en vigueur et constitue un cadre de référence en la matière.

En deuxième lieu, si l’article R. 55-5 du CPCE prévoit que L'identification de l'utilisateur lors de l'accès au service de coffre-fort numérique est assurée par un moyen d'identification électronique adapté aux enjeux de sécurité du service , la Commission relève toutefois que le cahier des charges ne vise que le niveau d’identification substantiel pour l’accès à un service de coffre-fort numérique. Elle estime en conséquent que ce cahier des charges devrait être complété afin de tenir compte des différents moyens d’identification électronique pouvant être proposés, y compris la possibilité d’ouvrir un coffre-fort numérique sous une identité déclarative, un nom d’usage ou un pseudonyme.

La Commission relève par ailleurs que l’identification de l’utilisateur ne pourra être réalisée au moyen du numéro d’inscription des personnes au répertoire national d’identification des personnes physiques (NIR) conformément à sa délibération n° 2013-270 susvisée. Elle rappelle en outre que l’utilisation de ce numéro d’identification est strictement encadrée par l’article 30 de la loi du 6 janvier 1978 précitée.

En troisième lieu, la Commission rappelle que l’article L.103-4° du CPCE prévoit la possibilité pour un fournisseur de service de coffre-fort d’accéder aux données à caractère personnel de ses utilisateurs pour réaliser un traitement de ces documents ou données au seul bénéfice de l'utilisateur et après avoir recueilli son consentement dans le respect de la loi n 78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés . Elle observe toutefois que le cahier des charges ne mentionne pas les modalités de recueil de ce consentement. Elle estime dès lors que le cahier des charges pourrait être utilement complété en ce sens.

En quatrième lieu, la Commission rappelle qu’en l’absence d’agrément ministériel pour l’hébergement des données de santé, le fournisseur de service de coffre-fort numérique a l’interdiction de traiter de telles données. Elle estime qu’une vigilance particulière devra être portée au respect de cette condition.

En cinquième lieu, la Commission rappelle que lorsqu’un service de coffre-fort numérique a vocation à conserver des données à long terme, elle recommande qu’une copie de sauvegarde de la clef de déchiffrement soit confiée à un tiers de confiance afin de permettre à l’utilisateur d’accéder à ses données en cas de perte de sa clef conformément à la délibération n° 2013-270 susvisé. Elle estime dès lors qu’une procédure de récupération de clef devrait être prévue dans le cahier des charges.

Enfin, la Commission appelle l’attention de l’ANSSI sur l’importance de prendre compte la réalisation d’une analyse d’impact sur la protection des données (AIPD) comme preuve de conformité au RGPD dans le processus de certification d’un service de coffre-fort numérique, dès lors que celui-ci peut comprendre des traitements de données à caractère personnel susceptibles d’engendrer un risque élevé pour les droits et libertés des personnes physiques.

-

La Présidente

Marie-Laure DENIS

Délibération n° 2013-270 du 19 septembre 2013 portant recommandation relative aux services dits de « coffre-fort numérique ou électronique » destinés aux particuliers

https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000028112009/

La Commission nationale de l'informatique et des libertés,

Vu la convention n° 108 du Conseil de l'Europe du 28 janvier 1981 pour la protection des personnes à l'égard du traitement automatisé des données à caractère personnel ;

Vu la directive 95/47/CE du Parlement européen et du Conseil du 24 octobre 1995 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données ;

Vu la directive 2003/98/CE du Parlement européen et du Conseil du 17 novembre 2003 sur la réutilisation des informations du secteur public ;

Vu la loi du 6 janvier 1978 modifiée relative à l'informatique, aux fichiers et aux libertés, notamment son article 11 ;

Vu le décret n° 2005-1309 du 20 octobre 2005 modifié pris pour l'application de la loi du 6 janvier 1978 modifiée relative à l'informatique, aux fichiers et aux libertés ;

Après avoir entendu Monsieur Jean François CARREZ, commissaire, en son rapport et Monsieur Jean-Alexandre SILVY, commissaire du Gouvernement, en ses observations,

---

Formule les observations suivantes :

La Commission nationale de l'informatique et des libertés constate que la dématérialisation de documents, après être entrée dans les mœurs du monde de l'entreprise, se développe à présent auprès des particuliers. La montée en puissance du commerce électronique ou des téléservices incite en effet ces derniers à diffuser, recevoir ou stocker plus fréquemment des informations les concernant sous forme électronique.

La centralisation de documents dématérialisés en un lieu unique est par nature risquée et pose des problèmes spécifiques au regard de la loi du 6 janvier 1978 modifiée, qu'il s'agisse de la destruction des données, de leur perte, de leur altération ou encore de leur divulgation à des tiers non autorisés.

À l'issue d'une concertation avec certains des principaux acteurs concernés, la Commission nationale de l'informatique et des libertés a souhaité préciser sa position vis-à-vis des services dits de coffres-forts numérique ou électronique.

1. Définition

Un espace de stockage numérique est un service qui a pour objet de conserver des documents dématérialisés sur un support informatique.

La Commission considère que le terme coffre-fort numérique, ou coffre-fort électronique, doit être réservé à une forme spécifique d'espace de stockage numérique, dont l'accès est limité à son seul utilisateur et aux personnes physiques spécialement mandatées par ce dernier.

La Commission estime que les services dits de coffre-fort numérique doivent garantir l'intégrité, la disponibilité et la confidentialité des données stockées et impliquer la mise en œuvre des mesures de sécurité décrites dans la présente recommandation.

Le fournisseur du service ne doit pas être techniquement en mesure d'accéder au contenu d'un coffre-fort, ni à ses éventuelles sauvegardes, sans le consentement exprès de l'utilisateur concerné.

La Commission estime qu'un service qui ne répondrait pas à ces critères et aux mesures décrites ci-après est un simple espace ou service de stockage numérique au sens de la présente recommandation.

2. Applicabilité de la loi du 6 janvier 1978 modifiée

Un service de coffre-fort numérique est un traitement automatisé de données à caractère personnel. D'une part, sa gestion repose sur des opérations informatisées. D'autre part, le contenu d'un espace de stockage est par nature lié à une personne physique identifiable.

La loi du 6 janvier 1978 modifiée est ainsi applicable à l'ensemble des services de coffres-forts numérique proposés aux particuliers par des sociétés établies sur le territoire français.

S'agissant des sociétés établies en dehors du territoire de l'Union européenne et proposant de tels services, la loi du 6 janvier 1978 modifiée leur est également opposable dès lors qu'elles utilisent des moyens de traitement en France.

La loi du 6 janvier 1978 modifiée n'est en revanche pas applicable à un espace de stockage numérique de documents créé par un particulier sur un support matériel lui appartenant, dès lors que seules des données le concernant y sont conservées pour son usage personnel.

3. Formalités préalables à la mise en œuvre d'un service de coffre-fort numérique

Le fournisseur d'un service de coffre-fort numérique détermine les moyens et les finalités dans la mise en œuvre du traitement. Il est ainsi, à la lecture de l'article 3-I de la loi du 6 janvier 1978 modifiée, le responsable du traitement et il lui appartient en cette qualité d'accomplir les formalités auprès des services de la Commission nationale de l'informatique et des libertés préalablement à la mise en œuvre du service.

Un service de coffre-fort numérique ou électronique doit faire l'objet, avant sa mise en œuvre, d'une déclaration normale auprès des services de la Commission nationale de l'informatique et des libertés.

La déclaration doit préciser, notamment, les catégories de données à caractère personnel traitées par le prestataire pour assurer son service (données d'identification des utilisateurs et données de connexion).

En revanche, les catégories de données stockées par les utilisateurs n'ont pas à être mentionnées dans la déclaration. En effet, il est impossible de déterminer à l'avance le type de documents qu'un utilisateur décidera de stocker dans son espace personnel, d'une part, et il est techniquement impossible de le savoir a posteriori puisque, par définition, le contenu d'un coffre-fort numérique ne doit pouvoir être consulté que par l'utilisateur concerné et les personnes mandatées par ce dernier, d'autre part.

La Commission nationale de l'informatique et des libertés estime que les opérations de récupération automatique de documents dématérialisés ne sont pas des interconnexions de fichiers issus de traitements dont les finalités principales sont différentes, dès lors que les documents ne sont pas utilisés par le fournisseur du service mais seulement introduits à un coffre-fort numérique.

En application de l'article 69 de la loi du 6 janvier 1978 modifiée, si les données stockées par les utilisateurs d'un service de coffre-fort numérique doivent être transférées en dehors de l'Union européenne par le prestataire, ce dernier doit obtenir une autorisation préalable de la Commission nationale de l'informatique et des libertés.

---

Recommande :

1. S'agissant des donnés traitées

Un fournisseur de service de coffre-fort numérique de documents est amené à traiter au minimum des données permettant d'identifier de façon certaine les utilisateurs, d'une part, ainsi que les données de connexion nécessaires au fonctionnement de son service, d'autre part. Ces catégories de données doivent figurer dans la déclaration du traitement accomplie auprès de la Commission nationale de l'informatique et des libertés.

La Commission nationale de l'informatique et des libertés rappelle que le traitement de certaines catégories de données est, selon les cas, interdit ou réglementé.

Ainsi, le numéro d'inscription des personnes au répertoire national d'identification des personnes physiques, c'est-à-dire le numéro de sécurité sociale, ne peut être utilisé pour le routage d'un document dématérialisé vers un coffre-fort numérique, y compris lorsqu'il s'agit de router des bulletins de paye. Les utilisateurs peuvent néanmoins stocker leurs bulletins de paye dans leurs coffres-forts électroniques.

Par ailleurs, l'hébergement de données de santé est soumis à un régime juridique spécifique. En effet, en application de l'article L. 1111-8 du code de la santé publique, les hébergeurs de données de santé doivent obtenir un agrément ministériel spécifique. La Commission nationale de l'informatique et des libertés considère, par conséquent, que les fournisseurs de coffres-forts numériques ne peuvent proposer à leurs utilisateurs de stocker des données relatives à la santé s'ils ne sont pas agréés à cet effet. Elle en déduit que la mise en avant du stockage de telles données ou son organisation, y compris la simple création par défaut d'un dossier santé par le fournisseur, nécessite impérativement l'obtention préalable de l'agrément ministériel précité. Les fournisseurs non agréés, quant à eux, doivent déconseiller à leurs utilisateurs de stocker des données relatives à la santé.

2. S'agissant des destinataires

Lorsqu'un service de stockage numérique est présenté comme un service de coffre-fort numérique , les documents stockés ne doivent être consultables que par l'utilisateur concerné et les personnes spécialement mandatées par ce dernier.

Le contenu d'un coffre-fort numérique doit ainsi être protégé par des mesures techniques les rendant incompréhensibles aux tiers non autorisés.

3. S'agissant des durées de conservation

Lorsqu'un utilisateur souhaite supprimer l'un des documents de son espace personnel, cette opération doit être immédiatement prise en compte.

Les copies répliquées en ligne du document supprimé doivent également être supprimées sans délais. Les éventuelles sauvegardes dans lesquelles peuvent figurer ces données ne doivent quant à elles pas être conservées au-delà d'un mois.

Il est toutefois possible de conserver brièvement un document qu'un utilisateur souhaite supprimer, notamment afin de détecter une éventuelle anomalie quant à l'utilisation de son espace personnel, ou de lui permettre de revenir sur sa décision en cas de mauvaise manipulation.

Lorsqu'un service de stockage numérique est présenté comme un service de coffre-fort numérique, le fournisseur du service s'engage quant à la pérennité du stockage. Par conséquent, la fermeture de ce type de service nécessite d'en informer les utilisateurs suffisamment en avance, afin de leur laisser le temps nécessaire pour récupérer les documents stockés.

4. S'agissant de l'information des personnes

De façon générale, en application de l'article 32 de la loi du 6 janvier 1978 modifiée, les personnes concernées par un traitement de données à caractère personnel doivent être notamment informées de l'identité du responsable du service, de la finalité poursuivie, des destinataires des données, des éventuelles transferts de données à destination d'un pays non membre de l'Union européenne, ainsi que de l'existence et des modalités d'exercice des droits d'accès, de rectification et d'opposition.

Les utilisateurs de coffres-forts numériques doivent, par conséquent, être clairement informés du type d'espace mis à leur disposition et de ses conditions d'utilisation.

Par ailleurs, lorsque que le fournisseur propose à ses utilisateurs un service de récupération de documents auprès de services tiers, basé sur la collecte des identifiants et mots de passe de l'utilisateur pour se connecter en leur nom à ces services tiers, il doit informer ses utilisateurs quant aux conséquences pouvant résulter de la collecte de leurs identifiants et mots de passe. En effet, une telle collecte peut constituer une violation des conditions générales d'utilisation de ces services tiers et des conséquences dommageables peuvent en résulter, telles que la perte du bénéfice d'une garantie ou d'une assurance.

La Commission nationale de l'informatique et des libertés recommande ainsi que les fournisseurs d'espaces de stockage numérique élaborent des solutions techniques permettant d'offrir des services de récupération de documents dématérialisés sans procéder à la collecte d'informations confidentielles.

5. S'agissant des mesures de sécurité

• le fournisseur d'un service de coffre-fort numérique ne doit pas être en mesure d'accéder aux données ou de les réutiliser. Des mesures techniques doivent être mises en place pour rendre les données incompréhensibles aux tiers non mandatés par l'utilisateur ;

• les données doivent être chiffrées avec une clef, maitrisée uniquement par l'utilisateur, conforme aux règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques éditées par l'Agence nationale de sécurité des systèmes d'information (ANSSI) dans son référentiel général de sécurité à l'annexe B1 ;

• lorsqu'un coffre-fort numérique a vocation à conserver des données à long terme, une copie de sauvegarde de la clef de déchiffrement doit être confiée à un tiers de confiance, afin de permettre à l'utilisateur d'accéder à ses données en cas de perte de sa clef. Toute utilisation d'une sauvegarde de la clef de déchiffrement doit faire l'objet d'une traçabilité et d'une information de l'utilisateur concerné ;

• lorsqu'un coffre-fort numérique a vocation à conserver des données à long terme, le fournisseur du service doit prévoir une évolution de la taille des clefs et des algorithmes utilisés, afin de garantir la confidentialité des données stockées dans le futur.

• tous les transferts d'information vers et depuis un coffre-fort numérique doivent être chiffrés lorsqu'ils sont réalisés par un canal de communication non sécurisé ;

• les fournisseurs doivent utiliser dans la mesure du possible des produits cryptographiques certifiés ou qualifiés par l'Agence nationale de sécurité des systèmes d'information (ANSSI) ;

• les fournisseurs doivent communiquer auprès de leur clients sur les mécanismes de chiffrement utilisés de la façon la plus transparente possible ;

• les fournisseurs doivent utiliser des mécanismes d'authentification robustes, de préférence des mécanismes d'authentification forte (mots de passe à usage unique, envoi de codes par SMS,...) et respecter les recommandations de la Commission nationale de l'informatique et des libertés dans ce domaine. En cas d'utilisation de mots de passe, des mécanismes réduisant les risques liés aux choix de mots de passe faibles doivent être mis en place ;

• les fournisseurs doivent mettre en place des mesures visant à garantir l'intégrité et la disponibilité des données (centre de stockage redondant, sauvegardes régulières, ...) et apporter des garanties en termes d'indemnisation des personnes en cas d'ineffectivité de ces mesures ;

• les fournisseurs doivent apporter des garanties fortes pour prévenir toute perte de données en cas de cessation d'activité ;

• les fournisseurs doivent rendre accessible, sans surcoût, un outil permettant aux utilisateurs de récupérer l'intégralité du contenu de leur coffre-fort de façon simple, sans manipulation complexe ou répétitive, et ce, afin de faciliter le changement de fournisseur ;

• les fournisseurs ne doivent pas inciter les utilisateurs à leur confier leurs identifiants et mot de passe permettant d'accéder en ligne à des services de la société de l'information sans les avoir préalablement informés quant aux conséquences de cette collecte ;

• lorsqu'un coffre-fort numérique permet d'échanger des données avec des tiers, le fournisseur doit mettre en place des mécanismes d'authentification de ces tiers ;

• les fournisseurs doivent proposer des fonctionnalités de traçabilité permettant aux utilisateurs de visualiser l'activité récente sur leur coffre-fort numérique, afin de détecter les éventuelles intrusions non souhaitées ;

• les fournisseurs doivent mettre en place des outils permettant de détecter et bloquer les connexions illégitimes aux coffre-fort numériques;

• l'effacement d'un fichier par un utilisateur doit être immédiatement pris en compte. Les copies répliquées du document supprimé doivent également être supprimée sans délai. Les éventuelles sauvegardes ne doivent pas être conservées au delà d'un mois, ce délai apparaissant suffisant pour palier une mauvaise manipulation de l'utilisateur ou corriger une anomalie ;

• les fournisseurs doivent informer leurs utilisateurs sur les mécanismes techniques qu'ils mettent en œuvre, afin de leur permettre de juger du niveau de sécurisation du service proposé ;

• les utilisateurs doivent être informés quant aux modalités de résiliation du service et de récupération des données stockées ;

• à défaut d'obtention d'une autorisation préalable de la Commission nationale de l'informatique et des libertés, les données collectées dans le cadre d'un service de coffre-fort numérique doivent rester sur le territoire de l'Union européenne, ou sur le territoire d'un État non membre de l'Union européenne garantissant aux données un niveau de protection suffisant au sens de l'article 68 de la loi du 6 janvier 1978 modifiée.

La présente délibération sera publiée au Journal officiel de la République française.

La Présidente

Isabelle FALQUE-PIERROTIN

• de Bastien Guerry gazette-bluehats@mail.etalab.studio
• le lundi 14 février 2022, 18h50

---

❤️ Joyeuse saint Valentin du logiciel libre ❤️

https://twitter.com/search?q=%23ilovefs

En cadeau, une gazette BlueHats 🧢 toute fraîche, avec son tour d'horizon habituel du logiciel libre et des communs numériques dans, par et pour l'administration publique :

https://communs.numerique.gouv.fr/gazette/bluehats_15/

Pour ceux qui n'ont pas vu, le pôle logiciels libres et l'école CentraleSupélec relancent un appel à idées pour que des stagiaires contribuent à votre logiciel libre, que vous soyez un organisme public, une entreprise ou une communauté :

https://communs.numerique.gouv.fr/bluehats/bluehats-semester-of-code/

Et pour le prochain atelier BlueHats du 25 février à 11h00, nous accueillerons Patrice-Emmanuel Schmitz qui présentera la licence European Public License, récemment autorisée pour la publication des codes sources de l'administration :

https://communs.numerique.gouv.fr/ateliers/

Lors du dernier atelier BlueHats, David Rongeat et Bertrand Mocquet ont présenté l'outil de l'Amue « VersLeLibre » qui aide à prioriser les ouvertures de codes sources :

https://communs.numerique.gouv.fr/ateliers/amue-verslelibre/

En prime, un rappel de la CNIL sur l'usage de Google Analytics :

https://twitter.com/codegouvfr/status/1491719210313076741

Bonne lecture !

— Bastien Guerry

• par Pôle logiciels libres d'Etalab/DINUM gazette-bluehats@mail.etalab.studio
• le 11/11/2021, 11:40

---

Bonjour,

la ministre Amélie de Montchalin a annoncé hier le lancement d'un « plan d'action logiciels libres et communs numériques » :

https://twitter.com/AdeMontchalin/status/1458507384125632520

Le plan d'action est en ligne sur le site de la DINUM :

https://www.numerique.gouv.fr/publications/plan-action-logiciels-libres-communs-numeriques/

Un nouveau site lui est consacré : https://communs.numerique.gouv.fr

... et la plateforme code.gouv.fr est lancée : https://code.gouv.fr

Vous pourrez suivre les contributions du nouveau pôle logiciels libres d'Etalab via cette gazette (prochain numéro mi-décembre) et Twitter :

https://twitter.com/codegouvfr

Bonne journée !

— Bastien Guerry

• le 2021-12-21

---

Date: Sun, 18 Apr 2021 13:52:11 +0200 From: NOREPLY-StartUnconditional@ec.europa.eu To: site-europa@marc-auer.fr

Intitulé de l'initiative citoyenne: Start Unconditional Basic Incomes (UBI) throughout the EU Vous recevez ce message parce que vous êtes abonné(e) aux mises à jour concernant l’état d’avancement de cette initiative. Ce message est envoyé par le groupe d’organisateurs de l’initiative concernée. Le contenu de ce message relève de la seule responsabilité des organisateurs. Le texte reflète uniquement l'avis de ses auteurs et ne peut en aucun cas être considéré comme reflétant celui de la Commission européenne.

Si vous ne souhaitez plus recevoir de courriels concernant cette initiative citoyenne européenne, veuillez envoyer un message à l’adresse SG-ECI-mailing@ec.europa.eu, en mentionnant l’intitulé de l’initiative concernée.

Veuillez noter que le traitement de votre demande par la Commission européenne peut prendre jusqu’à 15 jours ouvrables.

Veuillez ne pas utiliser cette adresse électronique pour envoyer des commentaires. Les commentaires envoyés à cette adresse resteront sans réponse.

Pour contacter le groupe d’organisateurs de l’initiative concernée, veuillez utiliser les adresses électroniques disponibles sur la page consacrée à cette initiative dans le «registre des initiatives citoyennes européennes».

! Traduction brute ! du 4 février 2021 depuis le blog Mozilla par DeepL.com (version gratuite)

---

Par Steven Englehardt et Arthur Edelstein, le 26 janvier 2021

Les traqueurs et les sociétés de technologie publicitaire abusent depuis longtemps des fonctionnalités des navigateurs pour suivre les gens sur le web. Depuis 2018, nous nous sommes attachés à réduire le nombre de moyens permettant de suivre nos utilisateurs. Comme première ligne de défense, nous avons bloqué les cookies des trackers connus et les scripts des sociétés de relevé d'empreintes digitales connues.

Dans Firefox 85, nous introduisons un changement fondamental dans l'architecture réseau du navigateur pour rendre tous nos utilisateurs plus sûrs : nous partitionnons désormais les connexions réseau et les caches en fonction du site visité. Les traqueurs peuvent abuser des caches pour créer des supercookies et peuvent utiliser les identifiants de connexion pour suivre les utilisateurs. Mais en isolant les caches et les connexions réseau du site web sur lequel elles ont été créées, nous les rendons inutiles pour le suivi intersite. Que sont les supercookies ?

En bref, les supercookies peuvent être utilisés à la place des cookies ordinaires pour stocker les identifiants des utilisateurs, mais ils sont beaucoup plus difficiles à supprimer et à bloquer. Il est donc pratiquement impossible pour les utilisateurs de protéger leur vie privée lorsqu'ils naviguent sur le web. Au fil des ans, on a découvert des traqueurs stockant des identifiants d'utilisateurs sous forme de super-cookies dans des parties de plus en plus obscures du navigateur, notamment dans le stockage Flash, les ETags et les drapeaux HSTS.

Les modifications que nous apportons à Firefox 85 réduisent considérablement l'efficacité des supercookies basés sur le cache en éliminant la capacité d'un tracker à les utiliser sur les sites web. Comment l'état du réseau de partitionnement empêche-t-il le suivi intersite ?

Comme tous les navigateurs web, Firefox partage certaines ressources internes entre les sites web afin de réduire les frais généraux. Le cache d'images de Firefox est un bon exemple : si la même image est intégrée à plusieurs sites web, Firefox chargera l'image à partir du réseau lors d'une visite sur le premier site web et, sur les sites web suivants, il chargera traditionnellement l'image à partir du cache d'images local du navigateur (plutôt que de la recharger à partir du réseau). De même, Firefox réutiliserait une seule connexion réseau lors du chargement des ressources d'une même partie intégrées dans plusieurs sites web. Ces techniques sont destinées à faire gagner du temps et de la bande passante à l'utilisateur.

Malheureusement, certains traqueurs ont trouvé des moyens d'abuser de ces ressources partagées pour suivre les utilisateurs sur le web. Dans le cas du cache d'images de Firefox, un traqueur peut créer un super-cookie en “encodant” un identifiant pour l'utilisateur dans une image mise en cache sur un site web, puis en “récupérant” cet identifiant sur un autre site web en intégrant la même image. Pour éviter cette possibilité, Firefox 85 utilise un cache d'image différent pour chaque site web visité par un utilisateur. Cela signifie que nous chargeons toujours les images en cache lorsqu'un utilisateur revient sur le même site, mais que nous ne partageons pas ces caches entre les sites.

En fait, il existe de nombreux caches différents dont les traqueurs peuvent abuser pour créer des supercookies. Firefox 85 partitionne toutes les caches suivantes en fonction du site de premier niveau visité : cache HTTP, cache d'images, cache de favicon, cache HSTS, cache OCSP, cache de feuilles de style, cache de polices, cache DNS, cache d'authentification HTTP, cache Alt-Svc et cache de certificats TLS.

Pour protéger davantage les utilisateurs du suivi basé sur les connexions, Firefox 85 partitionne également les connexions groupées, les connexions de prérecherche, les connexions de préconnexion, les connexions spéculatives et les identificateurs de session TLS.

Ce partitionnement s'applique à toutes les ressources tierces intégrées à un site web, que Firefox considère ou non que cette ressource a été chargée à partir d'un domaine de suivi. Nos mesures montrent un impact très modeste sur le temps de chargement des pages : entre 0,09% et 0,75% d'augmentation au 80ème percentile et en dessous, et une augmentation maximale de 1,32% au 85ème percentile. Ces impacts sont similaires à ceux rapportés par l'équipe Chrome pour des protections de cache similaires qu'ils prévoient de mettre en place.

Le partitionnement systématique du réseau rend plus difficile aux traqueurs de contourner les fonctions anti-pistage de Firefox, mais nous avons encore du travail à faire pour continuer à renforcer nos protections. Restez à l'écoute pour découvrir d'autres protections de la vie privée dans les mois à venir ! Nous vous remercions

La réarchitecture de la manière dont Firefox gère les connexions réseau et les caches n'a pas été une mince affaire, et n'aurait pas été possible sans le travail inlassable de notre équipe d'ingénieurs : Andrea Marchesini, Tim Huang, Gary Chen, Johann Hofmann, Tanvi Vyas, Anne van Kesteren, Ethan Tseng, Prangya Basu, Wennie Leung, Ehsan Akhgari et Dimi Lee.

Nous tenons à exprimer notre gratitude aux nombreux Mozilliens qui ont contribué à ce travail et l'ont soutenu, notamment Selena Deckelmann, Mikal Lewis, Tom Ritter, Eric Rescorla, Olli Pettay, Kim Moir, Gregory Mierzwinski, Doug Thayer et Vicky Chin.

Nous voulons également reconnaître les efforts passés et présents des collègues des équipes Brave, Chrome, Safari et Tor Browser pour combattre les super-cookies dans leurs propres navigateurs.

Traduit le 30 janvier 2021 depuis RemObjects.com sur une base fournie par DeepL.com (version gratuite)

---

Certains développeurs et fournisseurs d'outils, principalement ceux liés à des langages non gérés tels que C++ ou Delphi, définissent le développement natif comme la compilation directe vers le code-octet attendu par le processeur physique. C'est certainement une façon de voir les choses, mais nous pensons que c'est imprécis et que cela ne tient pas compte de la complexité des systèmes logiciels actuels. Prenons l'exemple suivant : si vous compilez une application pour x86, puis l'exécutez sur un processeur x64, est-ce vraiment « natif » ? On peut dire que non.

Le code non géré, natif du CPU, est de moins en moins pertinent de nos jours, et nous pensons que la véritable nativité du code, des applications et – surtout – de l'expérience du développeur se définit par d'autres critères.

Chez RemObjects, nous sommes fiers de fournir des solutions de développement logiciel véritablement natives pour une variété de plateformes. Nous considérons deux niveaux différents et séparés pour déterminer ce que nous considérons comme un développement « natif » : une expérience utilisateur native, et une expérience développeur native.

1. Une expérience utilisateur native

Qu'est-ce qui fait une expérience utilisateur native ? Pendant longtemps, il n'y a eu qu'une seule plateforme pour le développement grand public : Windows. Cela a changé et, dans l'ensemble, les utilisateurs choisissent leur environnement de travail par préférence. Même en évitant de se lancer dans la « guerre des systèmes d'exploitation », on ne peut ignorer que chaque plateforme actuelle a ses propres paradigmes d'utilisation distincts, et que les clients choisissent généralement leur plateforme informatique avec soin et souhaitent que leurs applications fonctionnent et se comportent bien sur ce système particulier, en adhérant aux paradigmes de leur plateforme.

Les utilisateurs de Windows s'attendent à ce que les applications se comportent « à la manière de Windows », et les utilisateurs de Mac veulent qu'elles fonctionnent « à la manière de Mac ». De même, les utilisateurs d'iOS veulent des applications pour leurs iPhones et iPads qui correspondent à la philosophie de conception de cette plateforme, et les applications pour téléphones Windows doivent une fois de plus adhérer à des paradigmes d'interface utilisateur complètement différents de ceux que les utilisateurs d'Android attendent de la plateforme qu'ils ont choisie.

Il est évident que le degré d'intégration des applications dans la plateforme qui les entoure varie : la plupart des jeux, par exemple, ont généralement une interface utilisateur plus ésotérique et indépendante de la plateforme (après tout, ils visent à vous sortir de votre routine quotidienne et à vous immerger dans une expérience de divertissement), tandis que les applications professionnelles et de productivité doivent généralement adhérer à la plateforme de la manière la plus stricte.

Le caractère natif n'est pas non plus uniquement dû à l'utilisation de contrôles et de thèmes d'IU de base exactement comme cela est prescrit. Par exemple, de nombreuses applications iPhone parmi les plus célèbres et les plus respectées ajoutent des textures ou des nuances subtiles aux contrôles fournis par le système d'exploitation. Mais elles continuent à se sentir « natives », car elles s'en tiennent aux paradigmes de base de l'IU, et les contrôles – tout en ayant l'air visuellement raffinés – ont un aspect, une sensation et, surtout, un comportement conformes aux attentes de l'utilisateur.

Pour ce faire, on utilise généralement ce qu'on appelle souvent les « ensembles de widgets natifs » des plates-formes. Qu'il s'agisse d'un bouton Win32 standard ou d'un bouton NSB natif du Mac, chaque ensemble de widgets offre un aspect et une convivialité uniques, qu'il s'agisse de l'espacement du texte dans les limites du rectangle environnant, de la taille des polices, des styles, de la force et de la direction des dégradés ou des détails complexes de la réaction et de l'animation du bouton lorsqu'on clique ou qu'on le touche. Ces détails subtils sont ancrés dans l'esprit de l'utilisateur ; celui-ci a des attentes subconscientes quant à la façon dont le contrôle sera ressenti lorsqu'il sera utilisé, souvent jusqu'au paramétrage du temps des animations. Ce qui peut sembler être une attention inutile aux détails devient crucial pour l'expérience de l'utilisateur, et celui-ci ressentira un effet de « vallée de l'étrange » si ses attentes ne sont pas satisfaites.

Mais le caractère natif va au-delà des simples contrôles offerts à l'utilisateur. La plupart des systèmes d'exploitation fournissent une infrastructure générale que les utilisateurs sont habitués à voir et avec laquelle ils travaillent – depuis les dialogues standardisés Ouvrir/Fermer ou Imprimer sur les ordinateurs de bureau jusqu'aux modèles de message électronique ou de tweet fournis par le système d'exploitation sur les téléphones.

Nous pensons que pour créer une expérience utilisateur véritablement native avec votre application, vos outils de développement doivent vous permettre de travailler avec les widgets et l'infrastructure natifs de la plateforme. Quel que soit l'effort déployé pour créer des bibliothèques “taille unique”, aucun bouton multiplateforme ne ressemblera vraiment à un bouton Windows standard, à un bouton Mac standard, à un bouton iOS standard. Afin de proposer à vos clients une application véritablement native, vous devez choisir une chaîne d'outils de développement qui vous permette de travailler avec la plateforme native.

Actuellement, ces chaînes d'outils comprennent .NET/WPF, Metro/WinRT, Delphi/VCL (pour Windows), Objective-C/Cocoa (pour Mac et iOS), MonoMac et MonoTouch (pour Mac et iOS, respectivement), Java (pour Android) ou MonoDroid (également pour Android).

Il va sans dire que chez RemObjects, nous essayons d'aider les développeurs à faire tous ces choix dans la chaîne d'outils. Que ce soit avec nos compilateurs (Oxygene, RemObjects C# et Swift) ou avec notre suite de produits Data Abstract, nous vous proposons une couverture complète de chacune des combinaisons énumérées ci-dessus.

Mais : nous pensons qu'une expérience utilisateur native, bien qu'essentielle, n'est qu'une partie d'un processus réussi de développement d'application.

2. Une expérience de développement native

À l'époque où Win32 était la référence en matière d'API pour les systèmes d'exploitation (et avant), les outils de développement devaient fournir de solides couches d'abstraction sur lesquelles les développeurs pouvaient travailler – parce que les API des systèmes d'exploitation étaient si basiques que travailler directement sur celles-ci revenait à travailler en langage assembleur (ou, en fait, à travailler en assembleur).

Lorsque des outils comme les plus récents Turbo Pascal, Visual Basic ou Delphi ont fait leur apparition, le développement avec les API DOS ou Win16/Win32 était une corvée. Les développeurs ont donc accueilli favorablement les couches d'abstraction qui facilitaient le codage, des bibliothèques de classes de base aux couches d'abstraction de l'interface utilisateur comme TurboVision, OWL, la VCL ou MFC.

Mais les plateformes ont évolué, et avec les produits Microsoft .NET et WinRT, Apple Cocoa (et Cocoa Touch) ou Android Dalvik basé sur Java, les API ont depuis longtemps atteint un niveau convivial pour les développeurs, un niveau sur lequel on peut et on devrait coder directement.

Les abstractions supplémentaires qui s'ajoutent à ces API sont une distraction, et non une aide, pour le développeur, car elles ajoutent une couche supplémentaire de surcharge inutile à l'application et à l'expérience de développement. Et ces abstractions se sont avérées être des échecs à plusieurs reprises, comme lorsque VCL.NET a essayé de reconstruire la bibliothèque de classes bien appréciée de Delphi sur le framework .NET (déjà beaucoup plus évolué et sophistiqué, mais orthogonal et donc incompatible, qui était alors dans sa version précoce 1.1).

Les abstractions inutiles d'API déjà bonnes (ou excellentes) ne servent à rien pour les développeurs qui les utilisent. Au contraire, elles séparent les développeurs de la plateforme, et les uns des autres. Pour chaque article, échantillon ou billet de blog fourni par, disons, Apple ou la communauté Cocoa qui montre comment utiliser une fonctionnalité d'iOS, il doit y avoir l'équivalent “et voici comment vous le faites dans MonoTouch”, “et voici comment vous le faites dans FireMonkey”, “et voici comment vous le faites dans ...”. L'abstraction empêche les développeurs de pouvoir (ré)utiliser la documentation ou les échantillons du fournisseur de la plateforme. Pire encore, elle fragmente la communauté des développeurs sur la même plateforme, empêchant les programmeurs d'interagir et de partager du code – chaque contrôle Cocoa écrit dans MonoTouch est un contrôle Cocoa qui ne peut pas être facilement réutilisé par un développeur utilisant la chaîne d'outils native Xcode/Objective-C (ni par un développeur utilisant FireMonkey, ou Titanium, ou toute autre couche d'abstraction).

Les abstractions empêchent également les développeurs d'adopter rapidement et facilement les nouvelles fonctionnalités de la plateforme. Lorsque les derniers SDK du fournisseur de la plateforme sortent, les développeurs qui utilisent les chaînes d'outils natives peuvent généralement commencer à travailler avec les nouvelles technologies dès le premier jour (ou même plus tôt). Dès qu'un nouveau SDK Android est disponible, les développeurs Java natifs peuvent utiliser les nouvelles API. Le jour même où une nouvelle version d'iOS est disponible, les développeurs Cocoa peuvent commencer à se salir les mains avec les nouveautés. Pendant ce temps, les développeurs coincés derrière une couche d'abstraction non native doivent attendre que leur fournisseur d'outils fasse l'abstraction des nouvelles API pour eux.

Sans parler du fait que les outils de développement non natifs vous enfermeront souvent et vous forceront à vous en tenir à la couche d'abstraction.

Le principal argument de vente et l'attrait d'une chaîne d'outils non native est généralement la “familiarité”, c'est-à-dire l'idée que la couche d'abstraction vous permettra d'accéder à une nouvelle plateforme sans la courbe d'apprentissage abrupte que représente, en fait, l'apprentissage d'une nouvelle plateforme.

Mais cela est trompeur et s'avère souvent ne pas être le cas. La principale courbe d'apprentissage sur une nouvelle plateforme n'est généralement pas le langage de développement, ni même le système de classes – il s'agit d'apprendre à connaître la plateforme elle-même et à écrire d'excellentes applications pour cette plateforme (ce qui nous ramène à notre premier critère : l'expérience utilisateur native).

Travailler avec une couche d'abstraction s'avère en fait avoir l'effet inverse de celui escompté, en rendant plus difficile la compréhension de la documentation du fournisseur de la plateforme (qui est entièrement adaptée aux outils natifs de la plateforme, bien sûr) et en rendant plus difficile la réutilisation des exemples de code existants trouvés en ligne.

Pour revenir au cas d'iOS : avoir à regarder et à comprendre la documentation ou les exemples écrits pour les API Objective-C de Cocoa peut sembler difficile si l'on n'est pas encore familier avec les paradigmes de l'Objective-C. Mais ce qui est en fait plus difficile, c'est d'avoir à regarder cette même documentation ou cet exemple, puis de comprendre comment il se traduit dans votre couche d'abstraction, disons, basée sur le C#.

Et aucune couche d'abstraction n'est jamais parfaite. La plateforme sous-jacente et ses API finiront par échapper au contrôle du développeur et il faudra s'en occuper. Tout effort visant à éviter de connaître et de comprendre la plateforme avant de développer sur celle-ci est malavisé et ne fait que retarder l'inévitable. Au bout du compte, il manque une fonctionnalité à l'abstraction et le développeur doit creuser jusqu'aux API de base et la mettre en œuvre lui-même. Ou alors, un bogue se produit qui nécessite un débogage plus important que ce que la couche d'abstraction prend en charge.

Comme pour l'expérience utilisateur native, ici à RemObjects Software nous nous sommes donné pour mission de soutenir (et d'encourager) les développeurs à utiliser des outils de développement natifs de la plateforme ; vous remarquerez que nous encourageons les développeurs à opter pour la chaîne d'outils plus native même dans les cas où recommander une solution moins native signifierait une vente supplémentaire pour nous.

En ce qui concerne le compilateur, une fois de plus, Oxygene, C# et Swift prennent en charge le développement natif sur les plateformes classiques Windows, Metro (Windows 8 et 10), Windows Phone, Android, Mac, iOS, watchOS et tvOS. Nos compilateurs sont également un excellent choix pour la construction de serveurs multiplateformes basés sur Mono ou Java.

Avec la suite Data Abstract, nous prenons en charge le développement natif pour toutes les grandes plateformes actuelles : Windows classique (via .NET et Delphi), Metro/WinRT, Windows Phone, Mac et iOS, ainsi qu'Android et d'autres plateformes basées sur Java.

Autres préoccupations, telles que la réutilisation des codes

Nous sommes bien sûr conscients que d'autres facteurs entrent en jeu dans la décision concernant la chaîne d'outils de développement. Des considérations telles que la réutilisation du code peuvent figurer plus haut sur la liste des priorités qu'une expérience de développement natif, et c'est normal.

Notre philosophie est que, toutes choses étant égales par ailleurs, les développeurs devraient viser une chaîne d'outils qui soit native sur les deux plans : l'expérience de l'utilisateur et l'expérience du développeur. Si nécessaire, un compromis dans l'expérience du développeur peut être fait – c'est après tout un compromis qui n'affecte que le développeur, s'il est poursuivi correctement. D'après notre expérience, aucun compromis ne devrait jamais être fait en ce qui concerne la fourniture d'une expérience utilisateur véritablement native.

En matière de réutilisation du code entre plateformes, nous, chez RemObjects Software, avons pour objectif d'aider, à la fois au niveau du langage (en fournissant aussi bien Oxygene que RemObjects C# et Silver comme langage natif du développeur pour toutes les principales plateformes, ainsi que leur bibliothèque Sugar) et au niveau de la base de données en arrière-plan, en maintenant la compatibilité avec le câble Data Abstract et en vous permettant de partager une infrastructure de serveur commune pour toutes vos applications clientes natives.

Pour en savoir plus

Vous pouvez en savoir plus sur nos produits à la fois multiplateformes et natifs Elements (Oxygene, C# et Swift) et Data Abstract, respectivement sur les sites remobjects.com/elements et remobjects.com/da.

Vous pouvez également trouver une matrice générale de la manière dont nos produits s'intègrent dans les différentes chaînes de développement natives (ainsi que semi-natives et non natives, si vous devez passer par là), à l'adresse remobjects.com/products/toolchains.

Ce sujet a été publié pour la première fois sur nos blogs.

…