Contexte du Projet

SightKick développe une application qui permet aux personnes aveugles et malvoyantes de participer aux jeux de société en autonomie totale, sans matériel adapté. L’app reconnaît les cartes et les éléments de jeu via le smartphone, puis transmet les informations au lecteur d’écran (VoiceOver sur iOS, TalkBack sur Android), qui les restitue dans l’oreillette du joueur.

Depuis juillet 2025, je suis founding engineer et CTO de SightKick, aux côtés de Florent Weltzer, fondateur et CEO. L’idée était née quelques mois plus tôt, pendant des vacances où Florent accompagnait son meilleur ami et le frère de celui-ci, Sam, aveugle. Une soirée jeux, une quarantaine de boîtes ouvertes, et pas un seul titre auquel Sam pouvait jouer en autonomie. Ce soir-là, jouer voulait dire l’exclure. Le projet venait de remporter le Startup Weekend de Mulhouse quand je l’ai rejoint, et cherchait maintenant son cœur technique.

Contraintes :

• Budget de startup en pré-amorçage, chaque euro compte
• Aucune brique technique existante, tout est à construire
• Un public utilisateur avec des besoins d’accessibilité non négociables
• Une forte incertitude sur l’approche technique viable pour la reconnaissance d’images

Approche : lean, itérative, incrémentale

Plutôt que d’investir lourdement dans une stack ambitieuse dès le départ, nous avons fait le choix inverse : aller au plus petit incrément possible à chaque itération.

L’objectif était triple :

• Minimiser le budget consommé à chaque cycle
• Permettre d’itérer plusieurs fois sur chaque question technique
• Garder la capacité de revenir sur une décision sans douleur

Cette discipline du plus petit pas possible a été la colonne vertébrale du projet. Elle nous a permis, à plusieurs reprises, de changer d’avis sur le cœur technique sans jeter des semaines de travail. Chaque décision restait réversible, parce qu’elle n’avait jamais coûté trop cher à prendre.

Stack technique

• Front-end : Vue.js en PWA (Progressive Web App), architecture hexagonale
• Back-end initial : aucun
• Back-end minimal : un passe-plat pour cacher les clés API des modèles de vision
• Back-end BETA : authentification et consentement de stockage des images, plus un service Python dédié à la reconnaissance d’images
• Cible : iOS et Android via PWA, compatible VoiceOver et TalkBack

L’architecture hexagonale du front a été précieuse : le cœur métier n’a jamais bougé quand la brique de reconnaissance d’images, elle, a été remplacée plusieurs fois.

Le cœur technique, trois itérations successives

Le plus gros défi du projet a été l’analyse des images elle-même. Nous avons procédé par benchmarks successifs, en gardant à chaque étape la possibilité de bifurquer.

Itération 1, les modèles de vision généralistes. J’ai benchmarké OpenAI, Mistral et Gemini sur notre cas d’usage. Chacun avait ses forces et ses limites en termes de précision, de latence et de coût par requête. Ces premiers tests nous ont permis de valider la faisabilité et d’identifier les contraintes réelles avant d’engager quoi que ce soit de plus lourd.

Pour ne pas exposer les clés API côté client (où elles seraient exploitables par n’importe qui), j’ai mis en place un mini back-end en passe-plat. Pas de comptes utilisateurs, pas d’authentification, rien. Juste un relais qui cache les clés et transmet la requête. Le plus petit back-end possible pour résoudre un problème précis, et rien de plus.

Itération 2, les premiers tests utilisateurs. Avec cette première version branchée sur un modèle sur étagère, nous avons organisé dès septembre 2025 les premiers tests avec des joueurs aveugles et malvoyants, grâce au soutien de l’association C’Cité. Les retours terrain ont éclairé la suite, bien plus que ce qu’un cahier des charges aurait pu produire.

Mais les LLM du marché plafonnaient autour de 90% de précision sur notre cas d’usage. Pour un jeu de société, c’est beaucoup trop peu. Une erreur par tour, et c’est une partie cassée. Les confusions les plus tenaces étaient d’ailleurs savoureuses : les modèles mélangeaient régulièrement les 0 et les cartes “interdit de jouer”, ou les 7 et les 1. Bref, il fallait un autre plan.

Itération 3, les modèles custom. À l’automne, Florent a rencontré David et Baptiste, deux experts qui nous ont aidés à entraîner nos propres modèles de reconnaissance d’images pour les cartes classiques et les cartes Uno. Cette bascule a porté la BETA de Noël 2025. Précision suffisante pour un usage réel, coûts de requête sous contrôle, et une indépendance vis-à-vis des fournisseurs de LLM.

Pour la BETA, le back-end a évolué : ajout d’une authentification et d’un consentement explicite pour le stockage des images, afin de permettre aux joueurs volontaires de contribuer à l’entraînement continu des modèles. Un second back-end en Python a été mis en place pour servir les modèles entraînés par David et Baptiste.

Chaque itération a été dimensionnée pour coûter le moins possible tout en apportant une information forte sur la direction à prendre.

Phases du Projet

Juillet 2025, démarrage technique

Cadrage de l’approche, mise en place du squelette Vue.js, première architecture hexagonale.

Été 2025, premiers développements

Branchement sur les APIs de vision, mini back-end passe-plat, boucle complète image → reconnaissance → lecteur d’écran.

Septembre 2025, premiers tests utilisateurs

Sessions avec C’Cité. Validation du concept sur Uno et cartes classiques, remontée des points de friction sur l’accessibilité et le rythme de jeu.

Octobre-Novembre 2025, accélérations externes

Intégration de l’incubateur Handilab, puis du Campus Louis Braille. L’écosystème d’experts accessibilité se met en place autour du projet.

Noël 2025, BETA publique

Lancement de la première BETA utilisable, avec modèles de reconnaissance custom, back-end d’authentification et service Python dédié.

Livrables

• PWA fonctionnelle installable sur iOS et Android
• Reconnaissance d’images pour les cartes Uno et les cartes classiques
• Compatibilité complète avec VoiceOver (iOS) et TalkBack (Android)
• Restitution multilingue dans la langue du joueur
• Back-end minimal d’authentification et de consentement pour le stockage d’images
• Service Python de reconnaissance d’images sur modèles entraînés sur mesure

Méthodologies Employées

Pratiques craft

• Architecture hexagonale pour isoler le cœur métier et rendre les briques techniques interchangeables
• TDD appliqué avec pragmatisme selon la nature des sujets
• Refactoring continu à chaque itération pour maintenir la qualité

Lean

• Plus petit incrément possible comme règle de base à chaque décision, y compris côté back-end
• MVP à chaque étape, jamais d’overbuild anticipé
• Feedback utilisateur intégré dès septembre 2025, puis en continu

Agilité

• Itérations de durée variable, rythmées par notre capacité à aller tester sur le terrain avec des joueurs malvoyants
• Priorisation dynamique selon les retours utilisateurs et les contraintes budget
• Réversibilité des décisions grâce aux petits pas

Apprentissages et Compromis

Ce qui a fonctionné

1. Le plus petit incrément possible. Cette discipline nous a permis de changer trois fois d’approche sur le cœur technique sans jamais jeter de travail important. À chaque bifurcation, la quantité de code impactée restait contenue, et le budget consommé limité.
2. L’architecture hexagonale sur un front-end seul. Souvent associée au back-end, elle a ici joué pleinement son rôle d’isolation quand les briques de vision ont été remplacées. Le cœur métier n’a pas bougé.
3. Un back-end qui grandit uniquement quand il le doit. D’abord rien, puis un passe-plat pour cacher les clés API, puis une authentification quand le besoin de consentement utilisateur est apparu. Chaque couche a été ajoutée au moment où elle devenait indispensable, pas avant.
4. Les itérations rythmées par le terrain. En calant la durée des cycles sur notre capacité à organiser des tests avec des joueurs malvoyants, nous avons évité de tourner en rond en interne sur des détails que les utilisateurs n’auraient pas validés.

Compromis assumés

• 90% de précision des LLM généralistes insuffisant, même après optimisation de prompt. Le passage à des modèles custom était inévitable, et le coût d’entraînement est devenu un investissement qualité plutôt qu’une dépense.
• Modèles custom plutôt qu’API généralistes, un choix qui demande d’entretenir les modèles mais divise les coûts de requête et améliore nettement la précision sur les jeux ciblés.

Conclusion

Ce projet illustre comment une approche lean, craft et itérative peut faire émerger un produit utile dans un domaine exigeant, avec un budget de startup en pré-amorçage.

Points clés :

• Le plus petit incrément possible est une discipline budgétaire autant que technique
• L’architecture hexagonale permet d’encaisser les pivots sans tout réécrire
• Un back-end minimal qui grandit à la demande évite la dette d’infra prématurée
• Caler le rythme des itérations sur le terrain, et non sur un calendrier interne, garde le produit aligné sur les vrais besoins

We need you !

Nous sommes toujours à la recherche d’utilisateurs pour tester l’app, de partenaires pour enrichir notre catalogue de jeux, et de talents techniques pour nous aider à faire grandir la plateforme.

Si vous êtes intéressé par l’accessibilité, les jeux de société, ou les deux, n’hésitez pas à nous rejoindre dans cette aventure !

---

Envie d’échanger sur un projet de startup tech, d’accessibilité ou d’approche lean et incrémentale ? Contactez-moi pour en discuter.