La 20ème édition de Paris Web a eu lieu du 25 au 26 septembre 2025. A cette occasion, l'association nous a proposé un "retour vers le futur" sur la création de cet évènement et un peu d'historique sur l'univers du web, en plus des traditionnelles conférences sur les standards, les normes, l'accessibilité, l'ergonomie, et les méthodes de conception.
On ne pouvait pas rater cet événement incontournable du web français qui s'adresse à un large public : développeurs, experts et expertes accessibilité et performance, chef et cheffe de projet, décisionnaires... Paris Web a 20 ans, comme le W3C, ça se fête !
On commence par une conférence anniversaire pour les 20 ans de Paris Web. C'est une conférence en deux parties.
Stéphane commence en racontant qu'en 2005 on retrouvait Flash partout sur le web sans notion d'accessibilité. On utilisait plein de plugins sans uniformité, et niveau sémantique web c'était la pagaille, renforcée par le fait que les moteurs de recherche ne regardaient pas la sémantique. Cette même année Stéphane a participé à l'évènement "@media" à Londres, le premier vrai évènement web à parler d'accessibilité. Il revient en France et veut créer un événement similaire car il n'en existe pas encore : "Si l'événement n'existe pas on a qu'à le créer". L'idée est de promouvoir le développement de qualité.
En 2006 c'est la première année de Paris Web, avec pour slogan "Webdesign, qualité, accessibilité". Y participe le directeur Europe de Mozilla, Tristan Nitot. Il y fait une conférence sur les 5 "C" du web de l'époque : la Culture c'est Wikipedia, le Commerce c'est Amazon et la Fnac, des Communautés se créent autour de hobbies via les forums, niveau Communication les individus commencent à avoir la même voix que les médias avec les blogs, et enfin le dernier "C" pour une catégorie de site dont la pudeur nous empêche de parler ici.
De 2006 à aujourd'hui, Paris Web a traité de sujets de société comme l'inclusivité, le green IT, le design, la typographie, la performance... Si on fait le bilan par rapport à 2005 : est-ce que niveau accessibilité c'est mieux ? Aujourd'hui on a les WCAG 2.2 et Aria, donc il y a des choses qui existent. Les plugins web et flash sont morts, tout est standardisé. Niveau sémantique c'est "presque bien", car les frameworks ne sont pas toujours au top.
Corinne prend la main pour la suite de la conférence, avec un regard sur son expérience côté staff. Elle revient après plusieurs années d'absence et remarque une même ambiance et des sujets de conférence toujours intéressants, un même public heureux. Elle explique pourquoi Paris Web est si particulier pour elle : les contenus sont hyper accessibles avec la vélotypie et la traduction en LSF, ainsi que captés et transmise en direct par Veodem. Elle raconte qu'au départ, avoir la traduction en LSF c'était la demande d'une personne de chez Maïf. Ce sujet a été géré par la Maïf au début puis repris par l'association par la suite.
La vélotypie est arrivée en 2009. On utilise des claviers spéciaux inventés en Hollande en 1980 qui permettent une saisie syllabique. Aujourd'hui ce sont deux personnes des chez System RISP qui s'en chargent à distance. Lorsque la première personne fait des erreurs, la seconde peut les corriger rapidement à la relecture.
La LSF a une place à part, c'est un élément essentiel en plus de la vélotypie. La LSF c'est comme le français, c'est une langue avec plein de subtilités, et la traduction en directe est fatigante pour les interprètes de Trilogue Interprétation, mais elles sont toujours là. Pour les 10 ans de Paris Web il y a eu une conférence sur la LSF organisée par les interprètes elles-même, drôle et instructive.
Le premier logo de PW était une licorne avec un arc en ciel et pendant longtemps les participants se sont appelés les "bisounours". Paris Web crée une émulsion qui donne envie aux participants de se joindre aux efforts, il y a de la bienveillance de tout le monde.
Cindy est Designer UI/UX, mais aussi ingénieure pédagogique, coordinatrice et formatrice pour étudiants sourds pour la formation "Concepteur Designer UI et Concepteur Développeur d'Applications". Elle crée des supports pour des formations de Design pour l'Académie des Sourdoués dont elle est membre. Sa vision : il faut une égalité et un accès aux métiers du numériques par les personnes sourdes. Par exemple, les devs sourds sont très peu présents. Aujourd'hui il n'y a quasiment aucun formateur sourd.
Chaque apprenant a un parcours éducatif différent. En général les sourds sont redirigés vers une formation basique, plutôt manuelle. Les professeurs disent aux enfants sourds "ce que tu veux faire ce n'est pas possible parce que tu es sourd" en leur demandant de s'adapter au cours alors que ça devrait être l'inverse. Il y a un effort cognitif d'apprentissage car en étant sourd la formation passe surtout par le plan visuel. Cela crée un décalage d'accès à l'information : les entendants baignent dans l'information, les sourds n'y ont accès que par la vision.
Aujourd'hui certaines formations se disent "inclusives" juste parce qu'elles font du sous-titrage. Mais pour Cindy ça ne suffit pas du tout pour une formation inclusive. Il faut absolument inclure la LSF dans une formation qui se dit inclusive.
Comment se passent les cours avec les apprenants sourds ? Les formations classiques sont plus compliquées à comprendre, parce qu'on passe de la théorie à la pratique et ce n'est pas forcément le plus adapté parce qu'il y a la difficulté d'associer le concept et le mot. Par contre, si on fait la pratique puis la théorie alors c'est plus facile. Le support pédagogique doit être en LSF pour la communication principale, les corrections et retours sont aussi en LSF. Les documents doivent être en FALC (Facile À Lire et Comprendre). Pour les cours à distance à l'époque du Covid, Cindy avait l'idée que le présentiel était indispensable pour maintenir un contact rassurant avec l'élève. Puis elle a réfléchi à son positionnement en tant que professeur : peut-être qu'un trop grand confort n'est pas ce qu'il y a de mieux pour l'élève car il faut qu'il soit autonome dans une entreprise réelle, ce qui inclut des situations de travail à distance. Ensuite elle a créé des supports pédagogiques qui permettent de travailler sur place ou à distance.
Elle utilise la méthode "Scaffolding" en 3 étapes. On commence par un soutien initial fort à l'étudiant. Dans un second temps il y a une transition vers l'autonomie : le professeur n'est pas toujours derrière l'étudiant mais lui fournit du feedback et les élèvent coopèrent. Le dernier temps est complètement asynchrone : c'est du travail personnel seul, en autonomie totale. Cindy termine la conférence en appelant à "faire la différence", en s'engageant vraiment et pas juste "faire des petits trucs" pour les étudiants sourds. "Une vraie égalité des chances dans le numérique n'est pas une option mais un engagement. Sans accessibilité, pas d'égalité". Il y a une vraie souffrance des personnes sourdes dans l'éducation, et l'Académie des Sourdoués offre une réponse adaptée. On peut y aller à partir de 18 ans et sans conditions d'entrée.
"Les mots de passe en 2025 c'est la cata". Leur mise en place pose des problèmes de sécurité et d'accessibilité. Les passkeys offrent une alternative : il s'agit d'un identifiant cryptographique lié à un compte sur un site, sur un domaine particulier, donc pas de phishing possible. On peut utiliser son empreinte ou une clé physique de type "Ubikey", ou bien un password manager, ou bien un QRcode... C'est "l'authenticator", l'objet ou le programme qui permet de s'identifier.
Les passkeys utilisent la WebAuthn qui est une spec W3C et la spec CTAP pour l'authenticator qui vient des standards FIDO. C'est une cryptographie asymétrique : on a une clé privée et une clé publique. Le fonctionnement se passe sur 4 niveaux : serveur, navigateur, authenticator, utilisateurice. Ce n'est pas pareil que la biométrie parce qu'on ne partage rien avec le service qui utilise cette méthode d'authentification : le service ne connaît que ce qui se trouve côté utilisateur.
Avec la librairie Spring on peut ajouter en 3 lignes les Passkeys sur une appli, puis on peut modifier l'interface de l'authentification.
Justine commence à nous parler des notices IKEA : quand on se trompe sur le montage il y a un jugement sur la personne plus que sur les instructions, alors que souvent les instructions sont responsables de l'erreur. "Dans la vie il y a la théorie puis la pratique". 97 % des sites en 2022 ont des défauts d'accessibilité dès la page d'accueil. Justine a réalisé des études sur l'accessibilité web et les déficiences visuelles sur plusieurs projets. Aujourd'hui elle n'est que messagère des utilisateurs, et les exemples qu'elle va donner sont issus de son expérience avec les personnes qu'elle a rencontrées.
Pour naviguer elle a vu des claviers virtuels ou grossis, la souris, mais aussi un crayon pour une utilisatrice qui ne pouvait bouger que quelques doigts. Les difficultés principalement rencontrées sont la saisie sur clavier ou utiliser la souris, la reconnaissance vocale qui ne marche pas bien, la fatigue et la baisse de concentration, la lecture difficile. Les personnes dyslexiques utilisent la navigation avec lecteur d'écran ou prédicteur de mots. Les difficultés rencontrées sont la fatigue d'entendre, le besoin de synthétisation.
Les personnes sourdes on accès a très peu de contenu traduit en LSF, ou ces contenus sont peu visibles. Pour les personnes qui ont un handicap visuel, les claviers braille coûtent très cher. Elles utilisent des contrastes inversés ou forcés, la loupe, une "zone curseur" pour repérer facilement le curseur, ou un curseur grossi, et demandent aussi l'aide de leurs proches. Les difficultés principales sont les captchas, les faibles contrastes, les formulaires, les caractères peu lisibles ou de trop petite taille, ou trop d'informations sur le site.
Justine présente ensuite des vidéos pour illustrer ses propos. Un utilisateur est perdu après l'ouverture d'un popin. Une image du site ne change pas de couleur ce qui provoque une douleur visuelle chez l'utilisateur. Un utilisateur est perdu car le formulaire qu'il remplit est en erreur sans expliquer pourquoi (le champ de saisie ne précisait pas de format de date de naissance et ajoutait les barres obliques automatiquement). Une personne sur un site de covoiturage est perdue car elle a ouvert le calendrier de l'OS (non verbalisé) et non du navigateur. Un utilisateur tape au clavier chaque caractère de son adresse car l'auto-complétion n'est pas verbalisée, et cela lui prend beaucoup de temps. Un utilisateur fait ses courses en ligne mais ne trouve pas de transcription écrite visible, facilement accessible. Une utilisatrice passe au panier pour finaliser ses achats mais est bloquée par le captcha en anglais et la consigne tronquée. Cette dernière expérience permet à Justine de préciser que les alternatives auditives au captcha sont très souvent inutilisables.
En prenant en compte ses expériences elle participe à la refonte du site des Champs Libres à Rennes, avec une roadmap qui prévoit des tests et scénarios appropriés. Dans une première phase de test réalisés par des personnes qui ont l'habitude de produire des audits, les difficultés critiques sont le manque de titres lus par les TA et les intitulés des menus peu clairs. En difficulté modérées on a des pages trop longues, pas assez de termes précis, la perte de focus après la recherche et l'ordre des éléments interactifs qui porte à confusion. Le taux de conformité était bien mais dans les faits l'expérience était loin d'être parfaite.
Justine conseille de faire les tests UX en amont et en présentiel, car cela permet à l'utilisateur d'utiliser son propre matériel. On peut utiliser des smileys pour les personnes ne souhaitant pas parler. On peut aider les utilisateurs, mais il faut bien le préciser sur le compte rendu. On peut poser des questions spécifiques sur l'accessibilité à la fin de l'entretien, par exemple sur les contrastes, ou demander si la personne s'est bien repérée sur le site entre les différents éléments. D'après son expérience, les personnes interviewées disent souvent à la fin de l'échange que le site est accessible alors qu'elles ont mis énormément de temps à naviguer dessus.
Il faut aller plus loin que le législatif, c'est toujours une question d'expérience avant tout. Le respect des normes (RGAA, WCAG) est essentiel mais il ne garantit pas une expérience pleinement inclusive pour les personnes handicapées. Il est indispensable d'impliquer directement les utilisateurs dans les tests et la recherche UX. De la même manière que l'on a poussé l'intégration des usagers dans la conception, il y a 15 ans, il faut faire de même avec les personnes handicapées. Il ne faut pas perdre de vue que cela reste de l'expérience utilisateur et donc faire preuve d'une certaine rigueur méthodologique lorsqu'on intègre les personnes dans la conception.
Lorsqu'on écrit du code sur un projet, comment cartographier des sentiers chaotiques, trouver des solutions à des problèmes frustrants ? Jérôme fait une analogie avec la randonnée. Sans un bon quadrillage du projet, ça ne marche pas. Il parle de différent problèmes qu'on peut rencontrer:
Le résultat lorsqu'on rencontre tous ces problèmes c'est ce qu'on appelle du code spaghetti : c'est le bazar. Alors comment résoudre ces problèmes ?
Jérôme fait ensuite une démonstration sur un bug rencontré. Il utilise l'outil Dependency Cruiser pour générer des schémas représentant le projet. Lorsqu'on travaille sur un projet il faut toujours un échange avec les équipes, toujours remettre ce qui est fait en question pour améliorer les processus. On peut mettre en place un mentorat entre les personnes plus seniors sur le projet et les débutants.
Le portail de l'audiodescription est un projet du gouvernement pour répondre à la problématique des films en audiodescription difficiles à trouver. Ce portail aide à référencer ces films hébergés sur les différentes plateformes de streaming. Au départ, Anne et Chloé identifient les points bloquants et les règles à respecter : pas de bandeau de cookie (donc pas de cookies), pas de connexion pour accéder au catalogue... Elles doivent inciter les plateformes de streaming à travailler leur accessibilité. Elles commencent à faire un prototype HTML sémantique au tout début, puis très vite un prototype qu'il faut tester rapidement.
Pour réaliser les tests utilisateurs, elles ont plusieurs canaux : recrutement par l'entourage, en interne, ou en passant par des associations. Il y a également le bouche à oreille qui fonctionne. Mais il y a un biais : les personnes volontaires sont souvent plus expertes sur les tests. Le contact est fait par mail, on passe les tests par téléphone ou par Zoom ("plus accessible" que les autres plateformes même si ça reste perfectible). Le consentement des personnes sur la récupération de leurs données est crucial en début de processus. Ensuite le test va durer au minimum 1h. Comme on travaille avec les lecteurs d'écran, il faut apprendre à ne pas parler en même temps que lui. Les tests sont fait auprès de différents types de personnes et l'équipe commence à créer des personas qui varient en fonction des contextes, de l'autonomie de la personne, de son aisance numérique.
Dans un premier temps les retours sont très bons et l'équipe est donc contente. Puis quand les vraies données sont implémentées alors les retours sont plus mitigés. Il y a de nouvelles problématiques : il n'est pas possible d'avoir un texte alternatif pour chaque affiche, les noms des plateformes sont mal prononcés car se sont souvent des acronymes ou des noms qui ne sont pas dans le dictionnaire. Les liens ne sont pas vocalisés, et il y a des accordéons qui compliquent la navigation. Certains termes ne sont pas compris comme "page active". L'équipe remarque des différences de besoins entre les utilisateurs experts et novices. Après ces retours Anne et Chloé font une version simplifiée du site : moins de liens, moins de composants. Elles sortent aussi un produit en parallèle pour les usagers qui n'ont pas l'habitude du web : l'Infolettre, qui devient plus cliquée que le site. N'ayant pas trouvé de solution satisfaisante de mailing elles doivent la créer à la main.
Les tests sont toujours en cours sur la plateforme : Anne et Chloé imaginent des tutoriels de navigation sur le site ou une version brute comme le site du Localisateur, ou une newsletter personnalisée. Les résultats de l'étude sont publiés sur le site des Designers Éthiques.
Damien commence la conférence en nous parlant de légumes : "Les légumes ça n'existe pas". Il n'y a pas de définition scientifique, un légume c'est juste la partie comestible de la plante, que ce soit une racine ou une tige. C'est un mot qui nous sert à appréhender les choses. En ce sens, les référentiels sont aussi des légumes. Mais les deux dont Damien va parler ont une approche différente.
Pour le RGAA l'objectif c'est la conformité totale en regardant le design, le code, le contenu du site. Pour le RGESN on est plus dans la réalisation d'une démarche, d'une amélioration, sur plein d'aspects comme le design et le contenu mais aussi l'architecture, l'UX, l'hébergement, l'usage de l'IA. Alors que le RGAA peut être audité en solo, le RGESN est une mission nécessairement collégiale à cause de la multitude de niveaux des critères. Il y a des notions de remise en cause des fonctionnalités implémentées, de poids, de dépendance à l'énergie du numérique (un vrai problème, quand on sait que Marseilles est la 7e ville au monde avec le plus de cable sous-marins à arriver, ce qui entraîne aujourd'hui un manque de place dans la ville). Il y a également des problèmes humains avec les ressources minées, comme l'esclavage en République du Congo. Le poids d'une page web a été multiplié par environ 180 entre 1995 et aujourd'hui...
Le RGESN est un des leviers français pour aller vers la sobriété numérique. C'est un référentiel assez récent qui date de 2022 et qui est donc amené à évoluer rapidement. Il contient 78 critères, répartis en 9 thématiques qui couvrent Internet et ses usages, la conception et le design, le développement et l'hébergement, l'administration et le contenu, la stratégie et l'engagement.
Damien nous présente son expérience sur le site des Champs Libres à Rennes. Le portail web est géré par une équipe qu'il connaît, et qui est très motivée. Ils décident d'apporter une réponse collective aux problèmes soulevés dans le RGESN. L'équipe est pluridisciplinaire et implique aussi des gens de la ville de Rennes. Il y aura un coordinateur avec un rôle qui ne sera pas celui de "l'expert RGESN" mais plutôt un rôle de facilitateur, de lien entre les équipes. C'est le garant de la démarche d'audit RGESN. Il n'y aura pas d'auditeur externe mais des parties prenantes avec une envie de le faire tous ensemble. Le projet s'est déroulé en plusieurs phases.
Au final ce travail a été étalé sur 2 mois, estimé à 80h de travail pour l'agence de Damien, LunaWeb. Des difficultés d'accès aux informations ont été évitées grâce à l'implication des commanditaires et des services tiers qui ont été coopératifs et engagés dans la démarche. C'est un succès dû aussi à la prise en charge rapide des différents aspects dans le projet. L'audit collectif a permis d'être plus pointu grâce à la présence de plusieurs experts, plus critiques, plus stimulants car tous ont eu envie de bien faire. Le RGESN est encore jeune et ne demande qu'à être amélioré : il y a un consortium officiel mis en place depuis quelques mois.
Le RGESN peut participer à l'accessibilité sur différents aspects : baisse de complexité du code et du produit, interdiction du défilement infini, compatibilité multi écrans, appareils et systèmes d'exploitation... On doit informer l'utilisateur de la nature des fichiers mais aussi des formats de saisie dans les formulaires.
Loïc a commencé à se poser des questions sur l'unicode à cause de son prénom. Pourquoi les deux points du "ï" de son prénom ne s'affichent-ils pas toujours alors qu'il n'y a pas de problème sur le point unique de "i" ?
L'unicode a été créé en 1991. C'est un standard créé pour rendre interopérable tous les systèmes d'écriture. Chaque caractère possède des caractéristiques catégorisées selon différentes normes. L'UTC définit les caractères de l'unicode. C'est une grosse structure qui est sous découpée, avec une contribution possible de l'extérieur. On est passé de 7000 caractères au début à 160000 caractères aujourd'hui. Ces caractères sont divisés en 17 plans qui ne sont pas tous utilisés et qui séparent les différents types de caractères. L'UTF-8 est un encodage de ces caractères répartis dans les grilles de caractères. L'unicode ne dicte par une forme définie mais attribue des labels collés aux codes qui déterminent la forme du symbole.
L'écriture latine ne prend que 0.25 % des caractères, alors que 62% sont des caractères chinois. On y retrouve des systèmes d'écriture modernes mais aussi anciens, des emojis et symboles, des notations, des ponctuations... L'unicode a un enjeu géopolitique : environ 50 % des langues sont en danger aujourd'hui, et une centaine de systèmes d'écriture sont menacés. Plein de nouveaux scripts sont en cours d'encodage. Comme le chinois contient beaucoup de variations, il existe un projet de standardisation des caractères qui est très politique et critiqué. 90 % des hiéroglyphes sont couverts dans l'unicode depuis le début, et les 10 % restants ont été ajoutés plus récemment.
Loïc nous présente certains symboles originaux : il y a l'enfant présent sur le Disque de Phaistos qui est toujours non décodé ou la tête de la mascotte du Japon de la Poste. Loïc précise que le Japon a d'ailleurs une place importante dans l'unicode avec l'invention des emojis qui y ont été ajoutés. Il y a le symbole japonais du débutant (drapeau vertical jaune et bleu) par exemple. Pour ajouter un emoji il faut compter plusieurs mois, sauf dans le cas des drapeaux : ils doivent être reconnus par l'ONU, ils sont alors ajoutés rapidement. Il y a un projet de rééquilibrage des émojis pour être plus représentatif du naturel. Il existe le Suiton Sign System, un système assez complexe qui utilise un assemblage de symboles représentant des gestes.
On peut participer à l'Unicode financièrement avec Unicod-adopt-a-caracter.
Le concept : des prises de parole successives de 4 minutes par personne. Pas le temps de terminer en 4 minutes ? La cloche sonne et c'est la fin de toute façon. Plusieurs talks avec ce format sont proposés à la fin de la première journée.
"Calligraphie en direct sous votre dictée" par Delphine Malassingne L'artiste a réalisé une calligraphie participative en 4 minutes avec des mots proposés par le public, calligraphie qui a ensuite été proposée aux enchères.
"Je suis une designeuse sous Linux" par Nathalie Rosenberg L'oratrice explique qu'elle fait du design sous Linux depuis un certain temps malgré les critiques et les jugements de ses pairs. C'est un choix politique quand on sait que la majorité des services utilisés aujourd'hui viennent des Etat-unis, qui est actuellement "politiquement instable".
"Donjons, dragons... et accessibilité" par Mewen Le Hô Présentation du créateur du site Allyquest : c'est un site interactif qui ressemble aux livres "dont vous êtes le héros" mais dont l'histoire reprend des notions d'accessibilité.
"Et si on arrêtait de parler de sexe dans les formulaires ?" par Sonia Prévost L'auditrice nous parle du problème de demander le "sexe" dans les formulaires : c'est un problème déjà pour les personnes qui ne rentrent pas dans les cases, mais aussi on peut se demander quel est l'intérêt. C'est une pratique qui date de quelques siècles en France pour déterminer les droits d'une personne : une femme a moins de droit par naissance qu'un homme. Quel est l'intérêt de poser cette question pour inscrire son enfant à des activités extra-scolaire ?
"Tour du monde des Design Systems d'états" par Anne-Sophie Tranchet Un talk sur les différents Design Système gouvernementaux. L'oratrice remarque que la couleur bleue, signe de confiance et d'apaisement, est très souvent utilisée, bizarrement.
"Avez-vous la base(line) ?" par Nicolas Arduin
"Pourquoi nous excluons... même quand nous croyons être inclusifs" par Luz Delgado Bautista L'exclusion : cette notion est à considérer tout le temps et pas juste envers les personnes qu'on considère socialement comme exclues : lorsqu'il y a des travaux dans la rue c'est excluant pour les personnes avec des poussettes
"Comment Paris Web a survécu pendant 20 ans ?" par Luc Poupard
Au début de cette deuxième journée de conférence, Tamara va nous parler de la question du validisme. Elle commence par expliquer des notions importantes. Les normes systémiques sont les règles d'un système, et ces règles favorisent des inégalités. Le validisme, c'est favoriser les personnes "valides" au dépend des personnes handicapées. Est-ce qu'une société validiste crée forcément un design validiste ? Tamara se pose donc la question à propos des personnes handicapées : "Est-ce que tout le monde s'en fout ?". Elle répond que non, que c'est plus de l'inconfort face au handicap, dû à l'ignorance. Il faut aller contre les idées reçues. Elle crée un jeu de cartes sur son site.
Tamara donne ensuite plusieurs conseils pour réussir à intégrer les notions d'accessibilité au sens des équipes. "Doser vos efforts" et ne pas tout balancer tout d'un coup, en un bloc. Il faut aussi déconstruire le jugement. Il y a un "ras le bol" de la bienveillance de la part de certaines personnes : plutôt que juger il faut plutôt encourager l'effort. Il ne faut pas juger les personnes trop vite alors qu'on peut se laisser surprendre par leurs raisonnements. Le fait de juger les autres est très lié au perfectionnisme renforcé / dû au capitalisme. "La théorie féministe du handicap" est un recueil de textes qui évoque l'utopie de la résistance de nos corps et nos esprits. On confond le productivisme (produire plus coûte que coûte) et la productivité (faire mieux avec moins). Il faut déconstruire les idées reçues par les activités et la formation.
Lorsqu'on fusionne le capitalisme avec le design on obtient un manque d'accessibilité, comme avec les Figma Sites (config.new). Adrian Roselli a écrit un article : "Ne publiez pas avec Figma Sites" à lire en suivant ce lien qui décrit l'ampleur du problème. Tamara demande : "Quel message on envoie" ? C'est comme l'utilisation des outils de surcouche, ça donne l'image qu'on ne prend pas ces sujets au sérieux. L'accessibilité c'est avant tout pour les personnes handicapées.
Il existe différents types de designers : design UX et design d'"art". Mais qu'est-ce qu'un bon design ? Tamara évoque l'exemple du canapé : on choisit un canapé en fonction de sa situation. C'est la règle des 3 U : utile, utilisé, utilisable. Tamara est allée voir sur Awwwards : c'est un site qui référencent d'autres sites récompensés car "très beaux" sur les critères de design / utilisabilité / créativité / contenu. Ces critères sont assez bizarres, on ne comprend pas bien ce qui entre dedans. Tamara fait passer des robots sur les 3 derniers gagnants. Le 1er n'est pas accessible du tout, le 2e n'expose pas son code, le 3e a 171 erreurs de contraste.
Tamara propose maintenant de passer à l'action, d'abord en posant des questions aux personnes autour de soi. La manière dont on pose des questions est importante pour ne pas braquer. Il faut accepter les réponses provisoires (même si les personnes qui donnent ces réponses ne savent pas que c'est provisoire). Il ne faut pas attendre que le problème arrive, et dire "Dites-nous si vous avez besoin d'un truc". Elle propose d'utiliser le Design Fiction, c'est à dire renverser ses schémas mentaux pour éviter les problèmes : qu'est-ce qui garantit l'échec pour les personnes handicapées ? Tamara préconise de faire des recherches inclusives avec des interviews et des tests utilisateurs. Tamara évoque de Chair et de Fer par Charlotte Puiseux, un essai sur le validisme.
La conformité et anti-validisme créent l'accessibilité. Il faut normaliser les besoins des personnes handicapées. Sortir de sa chambre d'écho : aller parler du sujet autre part. Se demander quoi faire non pour les gens mais avec eux. Encourager l'effort. Comprendre les mécanismes d'exclusion pour s'en défaire. Arrêter d'être dans le jugement. "Être aveugle c'est voir autrement" d'après Sylvie Duchateau, aveugle de naissance et experte en accessibilité numérique. On apprend des façons de penser et de voir les choses en échangeant avec des personnes handicapées.
Finalement, est-ce qu'il existe des exemples de bon Design ? Tamara nous parle de la définition du Larousse, et nous donne l'exemple du Banc de la paix devant le centre du prix Nobel de la Paix à Oslo, dont la forme pousse les personnes assises à se rapprocher. Tamara termine par une citation de C.S Lewis, écrivain: "Vous ne pouvez pas revenir en arrière et changer le début. Mais vous pouvez partir de là où vous êtes, et changer la fin."
Lucie a commencé à entendre parler du logiciel libre pendant ses études il y a 10 ans. Aujourd'hui c'est la présidente de l'AFPy. Le libre c'est 4 libertés : utiliser, étudier, redistribuer, modifier. Lucie nous donne des exemples de logiciels libres connus : Libre Office, Linux, git, Blender, Firefox, OpenStreetMap...
Pourquoi y participer ? Pour améliorer un logiciel, apprendre des choses sur les outils, apprendre à communiquer, rencontrer d'autres personnes. Que faire concrètement pour participer ? Écrire du code, ajouter des fonctionnalités ou debugger, mais si on a peur de casser des choses alors on peut aussi ajouter des tests ou remonter des bugs. Si on veut participer mais moins côté code : on peut améliorer l'interface, aider d'autres personnes à utiliser l'outil en faisant des tutos ou en participant à des forums, en écrivant de la documentation. Si on veut rencontrer des gens, on peut participer à des évènements.
Comment se lancer ? Il existe des guides de contribution ou des programmes de contribution avec des évènements. On peut regarder les tickets sur Github avec un label "first good issue" ou équivalent. On peut sinon demander à la communauté. On peut commencer en faisant une toute petite modification. On peut regarder les différents projets sur le site de l'association data for good. Pour les rencontres, on peut chercher des évènements sur l'agenda du libre, ou les Journées du Logiciel Libre ou JDLL, ou sur Meetup. Et si rien ne correspond à l'évènement qu'on recherche alors on peut le créer soi-même. Il y a plein de portes d'entrée et c'est un aventure intéressante et épanouissante. On peut aussi créer son propre logiciel libre mais c'est une autre histoire.
Le nouveau logo du W3C est arrivé ! En juillet 2025 c'était les 20 ans de MDN. Plus que de maintenance, François préfère parler de résilience ou même de robustesse. Le web est au cœur de l'infrastructure informationnelle, c'est un service rendu à une population large. François présente deux ouvrages utiles sur le sujet : "How infrastructure works" de Deb Chachra et "De l'incohérence" de Olivier Hamant. En 1989 le web c'est une proposition d'une dizaine de pages. Puis vient la création du W3C pour entrer dans les détails. En 2025 il existe 650 specs de navigations et environ 80000 concepts, des dizaines d'organisations et de groupes de travail. Les enjeux ne sont plus les mêmes, il faut vraiment s'occuper de la maintenance. Les specs sont les règles dès qu'il y a des conflits. Mais le problème c'est que les specs sont destinées aux implémenteurs (navigateurs), alors qu'il faudrait les ouvrir au plus grand nombre. Différents projets ont été créés pour ça.
Reffy est un exemple de projet qui a dégénéré, un outil de collecte de spec navigateurs. Browser-spec donne la liste des specs de navigateurs web. Ces outils valident l'adéquation entre spec et implémentation. Les résultats de Reffy sont sur le projet Webref. Et les données de Webref se retrouvent à plein d'endroits, dans Typescript par exemple. Cela crée une boucle de rétroaction pour remonter les problèmes.
Sturdy est un outil d'analyse. Sur le web la notion de "standard" est très importante. Dans les discussions courantes on parle de "features". WebDX est un catalogue qui liste environ 1000 fonctionnalités pour les devs. En découle la Baseline de chaque feature. Aujourd'hui 2/3 des features web sont supportées par les navigateurs (hors IE6). Les enquêtes "State of" font le lien avec l'usage réel des features.
Interop est un projet utilisé par les navigateurs. Sur les specs elles-mêmes des outils comme Bikeshed sont utilisés pour parser le code et faire des liens, ce qui permet aussi de repérer le code invalide. Il est important de trouver un équilibre entre la lisibilité et la complexité du code. C'est un effet systémique : tous ces outils permettent des échanges et des interactions dans le système au travers de process, tests, "guidelines", documentation, recherche, publication, analyse des specs... Il existe plusieurs groupes de règles. Le rôle du W3C est de permettre la collaboration entre ces groupes. Pour les développeurs, c'est bénéfique à plein de niveaux.
Au début de l'explosion du phénomène IA, Raphaël pense que c'est une technologie zombie : elle va sortir de terre de retomber rapidement, dans l'idée d'un buzz non viable. Mais ça ne s'est pas passé comme ça et aujourd'hui c'est intéressant de se poser la question de son impact dans nos métiers. Il y a assez peu d'études sur l'usage de l'IA, mais côté radiologie il y en a un peu car ce secteur utilise l'IA depuis plus longtemps.
L'IA est utilisée pour l'automatisation de transcription de rapports avec la reconnaissance vocale et la détection de fractures. Pour la transcription c'est un gain de temps et des compte-rendus construits selon le même schéma à chaque fois. Mais l'usage de l'IA entraîne moins d'activité mentale et une perte en qualité orthographique des secrétaires, mais aussi une perte de sécurité car les secrétaires pouvaient corriger les éventuelles erreurs des médecins. C'est aussi une augmentation de la charge de travail pour les radiologues. Pour la détection des fractures, c'est un filet de sécurité et une aide surtout pour les nouveaux médecins ainsi qu'un gain de temps relatif. Mais ça entraîne un apprentissage moins profond de ces nouveaux médecins, une acquisition plus lente des compétences, et une non détection des fractures peu conventionnelles.
Aujourd'hui se pose aussi la question de l'IA imposée dans nos outils. Raphaël nous parle d'une étude par Limites Numérique : Comment les entreprises de la tech nous forcent à utiliser l'IA. Il y a l'injonction : si je refuse d'utiliser l'IA alors le job ira à d'autres personnes. L'IA est déjà fortement utilisée pour le recrutement, ce qui amplifie les discriminations et permet d'éviter les contentieux : "Les outils automatisés pour l'embauche ne réduisent pas les biais du recrutement. Au mieux, ils les invisibilisent, au pire, les amplifient". On nous parle de backlog organisé, et de tâches attribuées par l'IA ; est-ce vraiment désirable ? Aujourd'hui il n'y a pas de preuve que l'IA augmente la productivité. Dans l'étude "Measuring the impact of early 2025 IA" qu'on peut lire en suivant ce lien, les résultats montrent que les personnes interrogées ont en moyenne l'impression qu'elles gagnent 20 % de temps en utilisant l'IA alors qu'en réalité elles en perdent 20 %, parce qu'elles négligent le temps passé à utiliser l'IA.
L'IA pose aussi la question de l'expertise. La différence entre un novice et un expert est la méta connaissance. L'IA possède juste des données. L'humain acquiert des connaissances par son expérience, par l'imitation, la collaboration, et la transmission de connaissance. Comment passer de novice à expert dans un monde rempli d'IA ? Il y a un risque de moins communiquer et de ne plus avoir de transmission de connaissance, et donc de stagner. Les modèles d'IA sont très bons pour converger vers un domaine connu, vers un même résultat. Lorsque appliqué au design, l'IA nous rabâche des clichés, sans aucune nouveauté.
L'IA dans les processus de design peut être utilisée dans la transcription d'entretien, la reconnaissance et réécriture de post-it, l'analyse sémantique, la catégorisation. Ce qui ne marche pas du tout, c'est de lui laisser faire une stratégie UX, le graphisme, la maquette, un design system, ou des mesures de l'expérience utilisateur. Les risques psychosociaux sont : la médiocrité du travail effectué, une lassitude cognitive, une évolution moindre des méta connaissances. Mais aussi une absence de co-construction, la perte des liens dans l'équipe, une prise en compte diminuée voir inexistante des utilisateurs finaux, une perte de sens du métier. Dans un futur désirable on envisage un usage frugal de l'IA, sur des tâches vraiment chronophages, ou en utilisant des petits modèles adaptés qui peuvent tourner en local sur nos machines.
Raphaël termine sur une citation de Frank Herbert dans Dune : "Il gardait en lui un peu de l'immoralité des temps anciens. Jadis, les hommes s'étaient laissés guider par des intelligences artificielles, des ordinateurs. Le Jihad Butlérien avait mis un terme à cet âge, mais il n'avait que partiellement triomphé de l'aura de vice du monde aristocratique qui continuait d'utiliser des machines."
Le terme de typographie accessible est apparu il y a environ 15 ans, alors que pendant 5 siècles, depuis l'invention de la typographie, on utilise plutôt le terme "lisible". La lisibilité du texte, c'est différent de la lisibilité des lettres. La lettre concerne la perception, le système visuel. Le texte est lié au déchiffrement et à la compréhension.
Damien nous parle de deux études : celle du MIT Agelab et de TRC, "The readability Consortium". La lisibilité du texte dépend du contexte, il n'y a pas de "meilleure typographie". Un concept très important pour la lisibilité, c'est la familiarité. "Les gens lisent le mieux ce qu'ils lisent le plus" d'après Zuzana Licko et Rudy VanderLans. Lorsqu'on lit on peut s'adapter à la typographie au bout de 20 minutes, mais il y a quelque chose qui nous dérange à cause du codage prédictif. Le codage prédictif c'est ce qui fait que les lettres familières sont traitées plus efficacement par le cerveau. Les préférences culturelles jouent aussi beaucoup.
Pour ce qui est de la lisibilité de la lettre, il existe plusieurs caractéristiques. L'écriture met en jeu plein d'éléments : cerveau, main, histoire, linguistique... L'écriture typographique est directement liée à l'écriture manuelle. L'écriture manuscrite a connu une évolution des lettres capitales, liée à l'adaptation de la vitesse de la main par les copistes. Janson utilise des lettres écrites du 15e siècle pour son modèle d'impression. Au début de la typographie les règles d'écriture sont très strictes. Et aujourd'hui encore respecter ces règles rend le texte plus agréable à lire.
Ensuite sont arrivés Caslon et Baskerville au 18e siècle, qui ont apporté une autre forme de caractères, puis Didot en France et Bodoni en Italie. Avec la 2e révolution industrielle, c'est la foison des typographies pour le marketing, il n'y a plus de respect des règles si strictes autrefois et on voit apparaître Futura sans serif, qui brise les codes, et n'est pas adaptée à la lecture. En réponse on voit apparaître Sans Gil.
Aujourd'hui quand on parle de typographie accessible il y a des notions d'espacement des caractères, de distinctions des formes qui entrent en jeu. En exemple de typographies accessibles on trouve Luciole en 2019, Frutiger en 1996, Rival sans en 2017, Galice en 2025, Atkinson en 2019. La forme des lettres est dictée par la plume plate, ce sont des fonts de type Human.
Pour déterminer si une typographie est lisible il faut se poser une question : est-ce une typographie de type Human ? Il n'y a pas de preuves, d'études sur l'accessibilité d'une typographie autre que pour Luciole. Mais Damien précise que les résultats de l'étude de Luciole sont à prendre avec des pincettes: c'est plutôt une confirmation que les typographies Humain sont les plus lisibles.
Comment choisir sa typographie ? Damien parle d'outils comme What the Font, Font Similarity ou Smart Search. En conclusion la lisibilité dépend du contexte et il faut toujours favoriser les typographies Human sans serif.
On ne voit pas le S de HTTPS dans le navigateur, sauf quand le site n'est pas sécurisé. Agnès veut rendre justice aux personnes qui ont œuvré à mettre le HTTPS en place. Le HTTPS, c'est HTTP avec TLS ("Transport Secure Layer"). Pour vérifier la sécurité d'un site on peut utiliser des services comme Mozilla Observatory ou sur CryptCheck. Pour ajouter le HTTPS sur un site on peut utiliser le service "Let's encrypt" (ou d'autres que nous verrons à la fin). La conférence va plutôt traiter de culture générale autour du HTTPS.
Il y a plusieurs phases qui se déroulent lorsqu'on visite un site en HTTPS, dont les suivantes : l'échange de clé, l'authentification, le chiffrement.
Pour le chiffrement on a besoin d'une clé de chiffrement et de déchiffrement. Un chiffrement peut être symétrique ou asymétrique. En HTTPS on utilise ces deux types de chiffrements, mais pas au même moment. Un chiffrement symétrique permet d'échanger plus d'informations. Il utilise un algorithme public et une clé secrète. Les algorithmes utilisés sont standards. L'idée de ces algorithmes est d'ajouter du désordre prévisible. La clé est partagée entre expéditeur et destinataire. Les algorithmes principalement utilisés sont CHACHA20 et AES ("Advanced Encryption Standard", chiffrement par bloc). Ce dernier ressemble à un jeu de taquin "énervé" (et non énervant car comme le précise à raison Agnès ce jeu est toujours énervant) auquel on va ajouter des maths. Comme le chiffrement symétrique est extrêmement rapide, on peut chiffrer tout internet. Mais il faut transmettre la clé secrète secrètement.
C'est la phase d'échange de clé : c'est le moment de l'ouverture du chiffrement. En anglais on dit "key agreement" : on se met d'accord sur une clé secrète en utilisant une clé publique. On utilise le protocole ECDH, où les lettres D et H sont là pour le nom "Diffie-Hellman". Mais que veulent dire les lettres E et C ? En chiffrement asymétrique, ce qui est chiffré avec la clé publique est déchiffré avec la clé privée. EC signifie "courbe elliptique" : on "marche" sur des courbes elliptiques, c'est un chaos de pas prévisible qui permet de déchiffrer.
Enfin, il y a la phase d'authentification. C'est là qu'il faut faire attention au "man in the middle" ("l'homme trouble du milieu" comme le présente Agnès, en référence au jeu Mass Effect). L'authentification se fait avec des signatures avec l'algorithme RSA ou un algorithme utilisant des courbes elliptiques. On passe par un tiers de confiance pour vérifier le certificat. C'est un système qui pose le problème des certificats expirés, sur des vieux ordinateurs par exemple.
Sur plusieurs services d'hébergement on trouve une case à cocher pour forcer le HTTPS, grâce à "Let's encrypt". En 10 ans, 90 % du trafic mondial est passé en HTTPS, en partie grâce à ce service. Mais "Let's encrypt" est américain, et cette utilisation massive peut être un danger au niveau géopolitique. Des certifications européennes existent comme Actalis en Italie ou Zerossl en Autriche. Le projet Elep est une association à but non lucratif pour un HTTPS européen, à suivre.
Un component est une brique d'interface autonome, qui facilite la réutilisation de code. Les Web Components sont proposés en 2011, adoptés en 2016, et continuent d'évoluer. C'est donc aujourd'hui un standard natif du web, indépendant des frameworks et compatible avec les navigateurs modernes. C'est un ensemble de plusieurs concepts, dont le shadow DOM et les custom elements. C'est l'usage du shadow DOM qui pose des problèmes surtout, car il crée une barrière entre l'extérieur du composant et l'intérieur du composant.
Nativement, les Web Components ont une syntaxe qui peut être rapidement complexe, c'est pourquoi on utilise des frameworks de Web Components comme Lit ou Stencil. Le principal avantage d'utiliser les Web Components, c'est que c'est un standard et donc la syntaxe reste stable : l'équipe est sortie de migrations de plusieurs frameworks et versions et recherchait donc cette stabilité. Un autre avantage est que les Web Components sont utilisables au sein de tous les frameworks. Mais le shadow DOM crée des problèmes d'accessibilité en rendant impossible le lien entre les composants. Plusieurs solutions de contournement sont possibles, comme encapsuler tout ce qui est concerné pour créer un gros Web Component. Finalement Simon et Nicolas préconisent une stratégie hybride, et pour les composants simples de privilégier le natif.
Lorsqu'ils ont fait réaliser des audits d'accessibilité, ils ont eu des problèmes avec des critères qui sont fondamentalement incompatibles avec les Web Components. Les outils d'audits ne prennent pas en compte le shadow DOM pour la plupart, donc il faudrait faire évoluer ces outils. Ils proposent que le RGAA s'adapte aux Web Components et non l'inverse.
Cette conférence propose un questionnement de notre rapport au numérique. Ignacio voyage au Chili chez sa tante : il va devenir un utilisateur du web dans un environnement contraint. C'est un endroit "reculé", à 15km d'un grand village, et la maison a un accès à internet de mauvaise qualité (une antenne est posée à environ 5 km). Mais surprenamment, sa tante arrive quand même à travailler de chez elle.
En fait elle a une utilisation différente d'internet. Elle utilise surtout sa connexion mobile et pose son téléphone a un endroit précis de la maison pour capter. La géographie entre l'antenne et la maison diminue la qualité du réseau. Il y a une sélection naturelle d'applications à utiliser, qui sont des apps à faible consommation. On peut regarder des films en streaming avec un temps de chargement long au début du film, mais ironiquement ils n'ont pas accès aux horaires des bus car la page ne charge pas. Comme le smartphone est placé en antenne, il y a aussi une utilisation différente du téléphone. Même avec un récepteur, la qualité d'internet est améliorée mais pas optimale.
Pourtant le Chili est un des pays avec la meilleure couverture internet d'Amérique du Sud, mais il reste des différences entre zone urbaine et rurale. D'après les études, au Chili l'accès au web se fait via smartphone dans 99 % des cas plutôt que via PC. C'est toujours une question de ressource : avoir internet c'est un coût. Un coût pour la qualité, pour la quantité avec le prix du mb, un coût en dispositifs d'accès qui deviennent vétustes dans les zones pauvres. Les inégalités s'additionnent.
En Europe il y a aussi des différences entre zones rurales et urbaines. Il existe une diversité de problèmes dans les zones rurales, mais aussi des problèmes dans les villes : trains souterrains, reliefs, agglomérations... Les antennes sont cachées partout. Dans les caractéristiques des zones rurales on trouve une démographie de 150 à 300 habitants par km2. C'est comme si toutes les personnes présentes à Paris Web étaient dans une zone quadrillée par quelques stations de métro à Paris. Il y a une grande distance entre les lieux. En zone rurale on a souvent moins de ressources économiques, des problématiques météorologiques spécifiques et une géographie plus contraignante. Comme il y a moins d'humains, le coût en infrastructure est proportionnellement plus élevé.
Est-ce que la couverture totale est nécessaire ? A quel coût et à quelle vitesse ? On peut trouver des solutions structurelles, comme repenser la couche numérique : est-ce qu'on a vraiment besoin du numérique partout ? C'est se demander si le numérique peut être une non obligation, et c'est une question qui fait particulièrement sens pour le service public.
Internet ce n'est pas la même chose que le numérique. Le modèle avec fournisseur d'accès à internet comme on a en France n'est pas la seule façon de faire. Le projet Mankosi est un FAI communautaire, il existe d'autres projets comme Rhizomatica, ou le projet Tegola en Ecosse. L'idée est de donner accès au numérique à des communautés éloignées. Au niveau applicatif on peut aussi changer de façon de faire : avoir l'information uniquement en local, par SMS, e-mail, ou autre... On peut imaginer des projets alternatifs pour permettre la communication dans le réseau sans avoir de connexion.
Il existe des solutions dans le monde immédiat. On peut concevoir responsable, en utilisant moins de données, en permettant un téléchargement non automatique, utiliser le "lazy loading" sur le web, le cache navigateur... Pour permettre l'accès aux dispositifs vieillissants il faut concevoir pour ces vieux dispositifs. On peut encourager le "Offline friendly" : permettre l'accès hors ligne, utiliser le cache HTTP, permettre de télécharger à l'avance... Enfin il est important de tester lors de la conception, de simuler avec les outils, et de faire tester par différentes personnes et environnements.
Il faut faire évoluer la vision des choses pour s'adapter aux multiples réalités humaines, aux différents contextes, et outils. La technologie n'est pas neutre. L'innovation reste à imaginer pour créer des voies alternatives.
Nathalie nous propose pour cette dernière conférence de partager sa collection de vieux sites. C'est une forme d'archéologie pour ne pas oublier le passé. Au début du web, celui-ci est très personnel. On trouve des blogs sur les passions, les hobbies. Il existe des plateformes dédiées comme Skyblog. Les créateurs de site web se copient les uns des autres, reprennent les mêmes images.
Globalement, les sites internet bougent de partout avec une profusion des gifs et animations. On retrouve des éléments aujourd'hui disparus, comme les liste de liens utiles, les livre d'or, les "web rings"... Il y a beaucoup d'images de petits chiens, et d'autres sujets sont très présents comme la musique Country, les villes, les étoiles qui clignotent... Certains en font même des projets artistiques. Le service Wayback Machine permet d'avoir accès aux sites supprimés.
Comme l'année dernière j'ai été très heureuse de participer à l'évènement. Dans la première conférence Corinne Durrmeyer parlait de "bisounours" ; c'est vrai qu'on se sent entourés pendant deux jours de personnes bienveillantes. Bravo et merci à toutes les personnes qui ont participé à cet évènement !
La conférence que j'ai préférée est celle de Damien Legendre, "RGESN : la force du collectif pour viser la conformité", et ce n'est asbolument pas (ou presque) parce que je suis arrivée à Rennes depuis peu et que j'aime beaucoup Les Champs Libres. J'ai trouvé que ça faisait vraiment du bien de voir un projet qui était mené à bien par une équipe motivée. Trop souvent on se retrouve avec quelques personnes impliquées sur le sujet de l'accessibilité ou de l'écoconception et qui n'arrivent pas à faire avancer les choses sur leurs projets, qui se retrouvent face à un mur infranchissable. Le témoignage de Damien m'a redonné l'espoir que ce n'était pas une fatalité, et qu'il était possible d'arriver à de vrais résultats avec un engagement commun.
J'ai également beaucoup aimé la conférence d'Ignacio Rondini, "Un web disponible, même sans Internet ?". J'ai trouvé ses exemples très pertinents, et la conférence a ravivé cette envie chez moi de "faire des choses simples" (ce qui n'est pas si simple) pour revenir à la base de nos métiers : créer des interfaces utilisables par des utilisateurs, quels qu'ils soient, et où qu'ils soient.
A l'année prochaine, avec plaisir !
Paris Web est réellement un événement unique dans le paysage du web français. Deux jours de conférences sur des sujets variés (développement, design, écoconception, sécurité, standards, typographie, ...) avec comme point commun l'accessibilité, l'inclusion et la qualité. C'est également un cadre bienveillant qui facilite les rencontres et les échanges entre les participants, les orateurices et les membres de l'association Paris Web. Bref un vrai moment de partage. Comme à chaque fois, ça passe trop vite mais on y apprend beaucoup. Enfin, Paris Web nous offre une bulle de décompression qui permet de recharger ses batteries en bonnes ondes pour l'année et on repart avec des idées plein la tête.
Un grand bravo et merci à l'ensemble des orateurices de cette année !
Mention spéciale à Tamara Sredojevic pour avoir réussi à me réveiller le matin du 2ème jour avec sa présentation passionnée et passionnante sur le Design validiste. D'autant plus qu'elle a réussi à placer dans ces diapositives une référence à mon film fétiche "Un jour sans fin" avec mon acteur favori Bill Murray. Mention spéciale également à Agnès Haasser pour sa présentation intitulée "le S de HTTPS". Agnès est une conférencière incroyable qui arrive à présenter un sujet très technique de manière compréhensive par tous. Son aisance est déconcertante. Et malgré une voix calme et posée, qui pourrait appeler à la sieste, elle arrive à nous maintenir en éveil et en écoute active sur un sujet de sécurité. Bravo à elle !
Paris Web 2025 est terminé. Mais je suis heureux d'avoir pu y participer. Un grand bravo à l'association Paris Web qui arrive année après année à organiser ce bel événement. Le temps va paraître long avant la prochaine édition. Ce sera avec plaisir que j'y retournerai.
Auteur(s)
Stéphane Einhorn
Développeur front-end @ Eleven Labs, and SEO lover...
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La 19ème édition de Paris Web a eu lieu du 26 au 28 septembre 2024 ! Qu'est-ce que c'est ? Un événement composé de deux jours de conférences et une journée d'ateliers sur les thématiques de l'accessibilité et de la qualité du web.
L'Anchor positioning API est arrivée en CSS depuis quelques mois. Expérimentale et uniquement disponible à ce jour pour les navigateurs basés sur Chromium, elle est tout de même très intéressante pour lier des éléments entre eux et répondre en CSS à des problématiques qui ne pouvaient se résoudre qu'en JavaScript.
Retour sur l'édition 2018 de dotCSS, la plus grande conférence au monde sur le CSS.