Planning BreizhC@mp 26

Swiper vite, taper en mode JIT, réagir en quelques millisecondes (Oh, Schumacher!). On conçoit souvent nos jeux autour de gestes précis et avec un gameplay peu ou pas accessible. Alors qu'un geste, c'est juste une méthode d'entrée : ce n'est pas le gameplay. Et quand on confond les deux, on finit par exclure des joueurs sans même s'en rendre compte ! L'idée de ce talk, c'est de penser autrement : partir des intentions du joueur (attaquer, explorer, interagir) plutôt que du geste qu'il doit faire pour y arriver. Une fois qu'on sépare l'intention de l'input, on peut proposer plusieurs façons de jouer. L'accessibilité devient un choix de design, pas un patch qu'on colle à la fin. Pour illustrer tout ça, j'ai construit Echo Quest, un petit "RPG" narratif avec Flutter et Flame. Ce n'est pas le jeu de l'année mais la démarche est expérimentale ! On y explore une forêt, on résout des énigmes, on se bat au tour par tour. Et surtout, on peut y jouer au tactile, au clavier, ou à la voix : le jeu s'en fiche, il reçoit la même intention. On verra ensemble comment : * structurer son gameplay autour d'intentions plutôt que d'inputs * brancher plusieurs modes de contrôle sur la même logique de jeu * utiliser ce que Flutter nous donne déjà (Semantics, focus, UI adaptative) * tirer parti de l'architecture de Flame (composants, overlays) pour mixer game loop et widgets Flutter accessibles * synthétiser de l'audio spatial avec Web Audio API pour naviguer sans écran * ajuster le rythme et la difficulté pour que chacun puisse jouer à sa façon L'accessibilité dans le jeu vidéo, c'est souvent le truc qu'on ajoute "si on a le temps". Vous l'aurez compris, je ne suis pas dev de jeu vidéo... je suis une dev mobile, concernée par l'accessibilité qui s'est laissé tenté par les jeux vidéos en 2D. Ce talk propose de montrer l'accessibilité autrement, à travers un jeu.

REX complet du déploiement de l'IA générative à la DSI de SIPA/Ouest-France : gouvernance, RGPD, sécurité, choix d'outils, cadre d'usage, mesure des gains — et les erreurs qu'on ne referait pas. Sans bullshit, avec les cicatrices. --- Déployer l'IA générative dans une DSI ce n'est pas juste ouvrir un compte ChatGPT à tout le monde. C'est une démarche qui touche à la sécurité, au droit, à la culture d'entreprise, à l'architecture, et surtout… aux humains. À la DSI de SIPA/Ouest-France (groupe de presse, ~200 personnes dont 60 développeurs), nous avons construit de A à Z une démarche baptisée IA4IT : structurer l'adoption de l'IA générative par les équipes IT, de façon maîtrisée et mesurable. Ce qu'on va raconter Le contexte et l'histoire Comment on est passés d'un usage sauvage et dispersé à une stratégie cohérente. Les signaux faibles, les premiers accidents, le moment où on a décidé d'agir. Les problématiques qu'on n'avait pas anticipées RGPD : quelle donnée peut-on envoyer à quel modèle ? CLOUD Act et souveraineté : jusqu'où peut-on aller avec des outils US ? Responsabilité juridique sur le code généré SSI : surface d'attaque, prompt injection, exfiltration de données Les outils sélectionnés et pourquoi GitHub Copilot, Claude (Anthropic), Cursor — comment on a comparé, négocié les contrats, configuré les garde-fous. Et ce qu'on a refusé. Le cadre d'usage Le document qu'on a co-construit avec les équipes : données autorisées/interdites, règles de revue du code généré, niveaux de confiance par outil. Comment le faire vivre sans que ça reste lettre morte. Le déploiement à l'échelle Plus de 200 utilisateurs, gestion des coûts (spending caps, licences mixtes), onboarding, formation, résistances. Les gains mesurés Métriques DORA, retours qualitatifs. Ce qui a vraiment changé — et ce qui est plus compliqué à mesurer qu'on ne pensait. Les erreurs et ce qu'on referait différemment Les vraies : sur la gouvernance des coûts, sur la communication, sur le rythme d'adoption. Sans langue de bois. L'accompagnement et les bonnes pratiques Comment embarquer les tech leads, les managers, les réticents. Ce qui marche pour ancrer les usages dans la durée. Pour qui ? DSI, architectes, tech leads, engineering managers — toute personne qui doit prendre des décisions concrètes sur l'IA générative dans son organisation, pas juste en lire des articles.

Vos utilisateurs en ont marre d’attendre... Nos applications s’essoufflent sous le poids du polling et des loaders plus ou moins maîtrisés . Et si les Server-Sent Events (SSE) étaient la solution simple et légère que vous cherchez ? Les SSE permettent de basculer d’un modèle où le navigateur demande à un système ou le serveur murmure à son oreille. Ce changement de paradigme a de nombreux impacts sur l'architecture, le code, et même sur la conception de l’expérience utilisateur. Charline et Nicolas, Lead Tech Frontend et Backend, vous partagent leur retour d’expérience sur cette mise en place dans des cas d'usages réels. Dans des jeux multi-joueurs, ou dans des applications de gestion traditionnelles, ils vous montreront les cas d'usages concret, les gains et les pièges à éviter. Venez découvrir comment les SSE influencent votre code, de l'intégration aux frameworks Frontend, jusqu'à la séparation lecture/écriture côté backend. Vous verrez aussi comment cette approche fait évoluer la conception des échanges Front/Back et l'expérience utilisateur, tout en offrant de nouvelles possibilités...

L’équipe projet ayant réalisé le portail de l’audiodescription du Ministère de la Culture vient partager ses apprentissages concrets en matière d’accessibilité. Comment mener des tests utilisateurs auprès d’un public déficient visuel ? Quelles bonnes pratiques d’UX/UI mettre en place pour proposer une expérience accessible au delà du RGAA ? Quels défis en développement cela représente-t-il ? Présentation des ratés et réussites de chaque étape du projet, de façon illustrée par un cas réel !

Alors qu'ils ont radicalement bouleversé notre façon de concevoir le déploiements des applications, les containers sont aujourd'hui considérés comme un "commodité", un détail d'implémentation. Le runtime qui leur permet de tourner n'intéresse que les experts lors de débats enflammés autour d'une pinte. Pourtant les choses continuent d'évoluer. Si on pourrait croire que l'architecture de Docker n'a pas changé depuis 10 ans, en réalité de nombreux composants évoluent pour assurer performance, flexibilité et sécurité renforcée. Par ailleurs, de nouveaux besoins apparaissent: avec la déferlante des agents IA, être en mesure de fournir un environment sans restriction tout en préservant son système hôte est devenu une nécessité. Je vais vous présenter dans les grandes lignes les nouveautés de containerd 2.2 avant de m'attarder sur le tout nouveau projet NerdBox qui permet de gérer des sandbox à base de microVM avec la simplicité des containers ... et -- cerise sur le gâteau -- sans avoir besoin d'être root 🤩