# BearStudio
> BearStudio is a French development studio based in Normandy, specializing in UX design, web and mobile development, and AI integration. We support digital project founders from idea to production.
## About (FR)
BearStudio accompagne les porteurs de projet pour les aider techniquement sur le développement web ou mobile de leurs idées.
Que vous lanciez un projet numérique innovant ou que vous ayez besoin de renforcer, refondre ou accélérer un produit existant, BearStudio est là pour vous !
## About (EN)
BearStudio supports project founders by providing technical assistance with the web or mobile development of their ideas.
Whether you are launching an innovative digital product or looking to improve, redesign, or scale an existing one, BearStudio is here to help!
## Services
### Design de vos applications
Nous concevons des interfaces utilisateur modernes et intuitives qui placent l'expérience utilisateur au coeur de chaque projet.
Notre approche UX/UI garantit des applications esthétiques, accessibles et ergonomiques pour maximiser l'engagement de vos utilisateurs.
### Développement d'application web et mobile
Nous développons des applications performantes et évolutives en utilisant les technologies les plus adaptées à vos besoins.
Du web au mobile, nous créons des solutions robustes et maintenables qui accompagnent la croissance de votre activité.
### Booster vos projets
Nous intervenons en renfort de vos équipes pour accélérer vos développements et apporter notre expertise technique.
Notre accompagnement flexible permet de débloquer vos projets et d'atteindre vos objectifs dans les meilleurs délais.
### AI Ready
Nous intégrons l'intelligence artificielle dans vos applications pour automatiser et optimiser vos processus métier.
Notre expertise IA vous permet de tirer parti des dernières avancées technologiques pour rester compétitif.
## Team
### Rudy Baer
Founder & CTO
Après un diplôme en informatique, j'ai fait mes armes en tant que développeur avant de devenir directeur technique (CTO). Mes années chez SmartPanda m'ont permis de développer d'autres compétences, telles que la gestion et l'administration de projets, tout en me familiarisant avec l'état d'esprit « startup ».
J'ai alors voulu tenter l'aventure entrepreneuriale en lançant mon studio de développement. C'est ainsi qu'est né BearStudio en 2016. Basés à Rouen, mais avec un réseau de clients internationaux, notre objectif est d'aider les chefs de projet à concrétiser leurs idées (site web, application...). Ma motivation première est d'aider les gens, d'avoir des conversations mutuelles, de se comprendre et, finalement, de faire progresser la collectivité.
Je suis également l'un des fondateurs et organisateurs de Fork it! Community. J'ai créé cette communauté après avoir fait un simple constat : je ne trouvais aucune communauté véritablement orientée vers le partage d'expériences, sans distinction de localisation géographique ou de technologie abordée. Au cours de mes voyages, j'ai remarqué que même les grandes communautés, bien qu'influentes dans leur région ou leur domaine technologique, restaient souvent confinées dans leur bulle.
### Ivan Dalmet
Co-founder & Lead Designer UX/UI
Ivan Dalmet est Lead Designer, product builder et co-fondateur de BearStudio. Avec plus de 15 ans d’expérience, il fait le lien entre design et développement pour concevoir des interfaces accessibles, efficaces et centrées utilisateur.
### Nhung Duong
Head Of Operations
Déterminée et pleinement investie, Nhung met son sens des affaires et son énergie au service de BearStudio depuis sa création.Polyvalente, elle intervient aussi bien en gestion de projet qu’en RH et en finance.Manager à l’écoute, elle accompagne les équipes au quotidien et contribue à une dynamique de travail positive, portée par son enthousiasme et sa rigueur.
### Yoann Fleury
Lead Front-End Developer
Avec une forte expertise en React et TypeScript, Yoann est Lead développeur Front-end et met un accent fort sur l'expérience développeur (DX), l'expérience utilisateur (UX) et aime concevoir des interfaces réactives, légères et accessibles. Il s'investit également beaucoup dans le partage, notamment en tant que mainteneur de projets Open Source (dont Start UI), l'organisation de conférence à travers le monde via Fork it! Community et une veille technologique accrue.
### Renan Decamps
Front-End Developer
Développeur Front et continuellement à la recherche du meilleur framework JavaScript, Renan aime tester toutes les nouvelles technos du moment.
Il rend fonctionnel l'ensemble des maquettes produites afin de donner vie à vos projets les plus fous !
### Nicolas Torion
Full-Stack Developer
Développeur Full-stack, Nicolas peut s'occuper aussi bien de l'implémentation de la logique de vos applications web côté back-end, de leur connexion à des APIs externes, que de leur intégration visuelle côté front-end. Considérant les technologies et langages comme des outils qui ont chacun leur intérêt selon le type de projet, il recherche toujours les solutions techniques les plus adaptées à votre projet.
### Hugo Pérard
Front-End Developer
Hugo est un front-end développeur passionné par le développement et la technologie. Son esprit avisé saura trouver la solution adéquate pour n’importe quel problème.
### Hugo Perez
Back-End Developer
Développeur Back-end, Hugo surnommé Hub possède également des compétences en Ops et en cybersécurité qu'il met à profit au BearStudio.
Il aime relever les défis et résoudre les problèmes sur les différents projets. Sa détermination et son expertise en font un atout précieux pour votre projet.
### Zouhair Mkassmi
Back-End Developer
Passionné par son travail, Zouhair incarne la rigueur même dans ce qu'il fait.
Notre développeur back touche à tout, il s'intéresse à ce qui touche au front aussi. Toujours à la recherche de solution, il n'hésite pas à consacrer tout son temps au problème !
### Aziz Ouertani
Back-end Developer
Développeur Back-end, Aziz met son énergie et sa curiosité au service des projets du BearStudio. Solide dans la conception et la logique métier, il est aussi sur la route du développement mobile et n’hésite pas à mettre les mains dans le front quand il le faut. Toujours motivé à apprendre et à explorer de nouveaux horizons, il sait s’adapter aux besoins et relever les défis techniques avec engagement.
### Grégoire Protas
Front-End Developer
Développeur Front, Grégoire a été plongé dès le début de son parcours dans les technologies de front React et React Native. Il fera son maximum pour vous proposer une solution adaptée à vos besoins.
### Noé Tatoud
Full-Stack Developer
Développeur Full-stack, Noé est toujours partant pour apprendre ou transmettre. Il construit des interfaces accessibles et évolutives et aime les projets où l’on prend le temps de bien faire les choses.
### Dylan Campbell
Front-End Developer
Développeur front-end, Dylan accorde une importance toute particulière à la Developer eXperience et la maintenabilité des applications. Il s'efforce de toujours trouver la meilleure solution, tant pour l'utilisateur que pour le prochain développeur.
### Marie Douet
Full-stack Developer
Tombée dans l'informatique au lycée lorsqu'elle a découvert la programmation, Marie privilégie la fiabilité, la simplicité et la cohérence dans ses projets. Curieuse et adaptable, elle sait tirer parti de chaque expérience pour progresser et donner vie à de nouvelles idées.
### Paul Smacque
Back-end Developer
Développeur back-end, Paul aime transformer des besoins en solutions concrètes et performantes. Toujours content d'apprendre en explorant de nouvelles expériences, son approche repose sur la résolution de problèmes complexes avec rigueur, fiabilité et efficacité. Il met un point d’honneur à fournir un travail de qualité, alliant sens du détail et pragmatisme.
### Daryl Avila Bonnet
UX/UI Designer
Sportif dans l’âme et curieux de nature, il aime apprendre et n’a pas peur de se tromper pour mieux avancer. UX/UI Designer passionné, il transforme les idées en expériences fluides et les défis en terrains de jeu créatifs.
### Héloïse Guillaume
Full-Stack Developer
Toujours prête à rendre service, que ce soit dans le quotidien ou dans ses projets tech, Héloïse aime participer à des initiatives variées, du web au mobile. Polyvalente et organisée, elle apprécie particulièrement jongler entre plusieurs projets en parallèle et contribuer là où elle peut avoir un impact.
### Hend Fellah
Manager du Camel Studio
Avec ma passion pour les échanges authentiques et les relations humaines, la gestion d’équipe n’a plus pour moi le caractère d’une contrainte professionnelle.
### Manuela Roberto
Office Manager
Manuela est office manager avec plus de 20 ans d’expérience en ESN, au cœur des univers de la dématérialisation documentaire et du jeu vidéo. Toujours en mouvement, elle jongle avec les priorités, anticipe, coordonne et fait avancer les projets avec une énergie communicative.
Fonceuse et ambitieuse, elle aime être sur tous les fronts et relever les défis sans jamais perdre le sens du collectif. Le théâtre d’improvisation, qu’elle pratique avec passion, reflète parfaitement son tempérament : réactive, audacieuse et résolument tournée vers l’action.
### Soraya Benchakroune
Assistante Full-Stack
Assistante en renfort sur la partie admin et compta, Soraya sait répondre à toutes les problématiques sans aucun stress
### Mariem Mkassmi
Full-Stack Developer
Curieuse, patiente et toujours désireuse d’apprendre, Mariem s’est reconvertie afin de développer des solutions techniques utiles, aussi bien en back-end qu’en front-end. Aujourd’hui, elle poursuit son parcours dans la tech avec enthousiasme, rigueur et la volonté de progresser chaque jour.
Développeuse passionnée et curieuse, toujours prête à concevoir des solutions utiles avec rigueur.
### Dylan Flandrin
Front-End Developer
Dynamique et autodidacte, Dylan (appelé "Trylan" en interne) sait mettre son énergie à profit dans la réalisation de vos projets. Très motivé et ayant soif d'apprendre, il ne lâche rien !
### Houssem Balti
Full-Stack Developer
Passionné par le web et la recherche de solutions, j’aime partager mes idées et échanger avec des personnes qui partagent la même curiosité. Toujours motivé par l’envie d’apprendre et de grandir ensemble.
### Jeanne Grenet
Junior Developer
À 12 ans, Jeanne savait déjà qu'elle serait développeuse. Elle a à coeur de concevoir et développer des interfaces utiles et cohérentes, au plus proche des besoins des utilisateurs. Curieuse de nature et toujours en quête d’apprentissage, elle s'investi autant sur les projets que dans l'organisation de conférences avec Fork it! Community.
### Vivien Murguet
Junior Developer
Passionné d’informatique depuis l’adolescence, Vivien a commencé à développer sa créativité sur RPG Maker XP avant d’explorer de nombreuses évolutions technologiques. Ingénieur de recherche et biologiste de formation, il s’est reconverti dans le développement pour transformer une passion de longue date en métier. Curieux et polyvalent, il aime expérimenter différents langages et outils sur ses projets personnels. L'IA fait aussi partie de ses intérêts personnels et professionnels.
Au BearStudio, il développe principalement en NodeJS, ReactJS et TypeScript en interne. Il met également ses compétences transversales et son sens du détail à profit pour aider dans les tests et revues de code, texte et vidéo, ainsi que dans l'amélioration du SEO technique et organique.
### Justine Leborgne
Junior UX/UI Designer
Designer UX/UI junior, Justine se spécialise dans la conception d’interfaces fonctionnelles et structurées, respectant les standards UX/UI. Elle met son sens du détail au service d’expériences utilisateur claires et cohérentes, en s’appuyant principalement sur Figma pour traduire les besoins en solutions visuelles pertinentes.
### Éléa Viscat--Provost
Junior Community Manager
Community Manager junior en alternance, je participe à la communication et au marketing de Bearstudio et Fork it! Community, notamment à la création de contenus et à l’animation des réseaux sociaux.
## Blog Articles (FR)
### IA & Client : les "Vibecodeurs"
URL: https://www.bearstudio.fr/fr/blog/articles/ia-et-client-les-vibecodeurs
Date: 2026-05-12
## Dans l'article précédent
Dans le premier article sur [les clients "prototypeurs"](/fr/blog/articles/ia-et-client-les-prototypeurs), j'ai présenté comment nos clients utilisent désormais l'IA pour prototyper leurs idées, transformant ces "shadow prototypes" en véritables spécifications.
Mais une nouvelle étape commence lorsque les clients ne se contentent plus de montrer... mais veulent **construire avec nous**.
## Faire face à la vague de clients "vibecodeurs" : comment on a dû s'adapter
Le cas de Client A était une première étape : accepter l'IA comme un outil de spécification. Mais avec un autre client (appelons-les "Client B"), nous avons fait face à une réalité bien plus chaotique.
Ils évoluent avec les mêmes contraintes budgétaires, mais cherchent à livrer davantage de fonctionnalités en travaillant avec nous plutôt qu'en nous remplaçant. Leur objectif est de nous confier le travail lourd, transverse et orienté maintenance, tout en conservant l'autonomie nécessaire pour traiter eux-mêmes des tickets de backlog restés en attente. Cette approche leur permet d'adresser des sujets qu'ils ne pouvaient pas prioriser auparavant, tout en s'appuyant sur nous pour la revue et le cadrage lorsque nécessaire.
Le problème ? Ils ne nous avaient rien dit au départ. Un jour, ils m'ont simplement envoyé une pull request entièrement "vibe codée", sans contexte, sans description de ticket, et sans même qu'elle soit référencée dans le backlog.
Première réaction ? La confusion. J'ai passé des heures à analyser le code, à tenter de reconstituer l'intention, l'impact et ce qui devait être testé. Ce n'était pas soutenable. Je ne pouvais pas simplement "corriger" leur code ; j'avais besoin que nous corrigions la collaboration.
Finalement, ils sont revenus vers nous avec une proposition qui ferait frémir la plupart des développeurs traditionnels :
> Nous n'avons pas le budget pour que vous construisiez tout. Nous voulons "vibe coder" des fonctionnalités avec vous. Vous gérez le coeur du système, nous gérons le reste.
Le réflexe initial :

Il y a deux ans, notre réponse aurait été de fortement décourager cette approche, à cause du coût de revue et de maintenance.
Dans un modèle d'agence traditionnel, l'équipe de développement est en charge du code en production. Les contributions sont donc strictement contrôlées pour garantir cohérence, fiabilité et sécurité. Toute modification externe peut introduire des défauts ou des risques dont l'équipe reste responsable, rendant ce type de contribution difficilement viable.
Mais comme le dit souvent [Rudy](/fr/equipe/rudy-baer) : **« S'adapter ou disparaître. »**
Si nous avions refusé, Client B aurait simplement fait appel à un freelance peu regardant sur la qualité, ou aurait tout tenté de son côté... avec un crash probable quelques mois plus tard.
## Le nouveau processus : la stratégie des "guardrails"
Nous avons accepté le défi. Mais pour que cela fonctionne, nous avons dû déconstruire notre processus de production et le reconstruire autour d'un nouveau principe : **nous ne sommes plus les auteurs de chaque ligne de code, nous en sommes les éditeurs**.
Voici le workflow précis que nous avons mis en place pour survivre au "vibe coding" :
### 1. Le "pre-code check" (phase de planification)
Client B utilise Claude Code avec la fonctionnalité de planification. Désormais, au lieu de coder immédiatement, ils génèrent un plan. Nous intervenons à ce moment-là. Nous analysons leur brief et le plan proposé par l'IA. Nous itérons sur la logique avant qu'une seule ligne de code ne soit produite. Si le plan est mauvais, le code le sera aussi. Nous corrigeons le plan, pas le produit fini : on simplifie l'architecture, on optimise les process, on vérifie les différents cas métiers etc.
### 2. Le contexte est roi (agents.md)
On ne peut pas laisser une IA deviner l'architecture. Nous avons défini avec eux des règles strictes de contexte : fichiers agents.md, "skills", standards de code (linting, audits de sécurité). Nous avons, en quelque sorte, appris à leur IA à se comporter comme un développeur BearStudio. En parallèle, le client lui apprend ses règles métiers et son intention.
### 3. L'intégration plutôt que les tests unitaires
Historiquement, les tests unitaires étaient souvent limités par des contraintes de temps et de budget. Aujourd'hui, avec l'IA, nous pouvons en générer systématiquement, beaucoup plus rapidement, ce qui permet d'assurer un premier niveau de sécurité sans effort supplémentaire significatif.
En revanche, le véritable changement se situe au niveau des tests d'intégration. Nous renforçons fortement cette couche, car elle devient essentielle dans ce contexte.
Le client définit les scénarios de test, puisqu'il est à l'origine des fonctionnalités, et l'IA peut ensuite enrichir ces scénarios avec des cas limites ou des variantes auxquelles nous n'aurions pas forcément pensé.
Les tests locaux et avec le client en environnement de pré-production en sont d'autant plus efficaces que l'on a une première check list à vérifier.
### 4. La nouvelle approche des pull requests
Nous avons mis en place une auto-revue par IA pour les bases avec l'utilisation des skills de review : general, security, architecture... La revue humaine, elle, a changé de nature. Nous ne cherchons plus les erreurs de syntaxe (le linter s'en charge). Nous analysons la cohérence architecturale : est-ce maintenable ? Est-ce aligné avec l'existant ? Est-ce performant ?
### 5. Quand l'IA transforme la dette technique en accélérateur
Un autre signal fort est apparu avec Client B : la question des mises à jour majeures.
Depuis des années, nous recommandions une montée de version importante. Le projet a près de dix versions de node de retard. Comme souvent, ce sujet n'était jamais priorisé : aucun bénéfice visible, difficile à justifier côté business.
Mais récemment, la demande est revenue... initiée par le client lui-même, après recommandation de l'IA elle-même.
Ce n'est plus un sujet abstrait de "dette technique". C'est devenu un blocage concret à sa capacité d'expérimentation. Les outils modernes ne fonctionnent plus correctement, et certains assistants ne peuvent même pas exécuter les commandes de build sur un environnement obsolète.
**L'IA n'a pas créé le besoin technique. Elle l'a rendu visible et urgent.**
Pour la première fois, cette mise à niveau n'est plus perçue comme un coût, mais comme un accélérateur.

## Le bénéfice inattendu : dompter le legacy
Ce chaos a révélé une opportunité.
Le projet reposait sur un code legacy complexe, difficile même pour nos équipes.
Nous avons constaté que l'IA, bien guidée, pouvait naviguer dans cette complexité plus rapidement que nous. Là où il aurait fallu plusieurs jours d'analyse, certaines fonctionnalités sont générées en quelques heures.
Nous avons réalisé qu'en déléguant le "codage" à l'IA du client, nous allions plus vite, mais cela nous imposait d'accepter un changement de rôle.
**Nous ne sommes plus les seuls auteurs. Nous devenons les éditeurs en chef.**
## La règle d'or
Même avec les meilleurs processus, fichiers agents.md et revues automatisées en place, on ne peut pas simplement laisser une IA se balader librement dans l'ensemble du codebase. Pour que ce modèle de "co-construction" fonctionne, nous avons dû établir une règle d'or avec nos clients pour déterminer qui construit quoi.
Tout se résume au **rayon d'impact** d'une fonctionnalité. Nous divisons la roadmap en deux catégories : **Local** et **Transverse**.
### 1. Les fonctionnalités locales (terrain de jeu du client)
Les fonctionnalités locales sont isolées. Ce sont les composants UI autonomes, une page de paramètres spécifique, un nouveau widget de dashboard, ou une interface CRUD (Create, Read, Update, Delete) basique. L'IA excelle ici. La fenêtre de contexte requise est petite. Si l'IA du client hallucine ou écrit du code brouillon ici, le pire scénario est un bouton cassé ou une div mal alignée.
**Notre position : lâchez-vous.** "Vibe codez" ces fonctionnalités aussi vite que vous voulez. Tant que ça passe le linter et les contrôles de sécurité de base, nous mergeons.
### 2. Les fonctionnalités transverses (la forteresse BearStudio)
Les fonctionnalités transverses sont le système nerveux de l'application.
Cela inclut le routing, le state management, l'authentification, les schémas de base de données et les intégrations profondes avec le code legacy. Ces fonctionnalités touchent tout. Si vous modifiez un composant transverse, vous risquez une défaillance en cascade sur l'ensemble de l'application.
L'IA peine notoirement ici car elle ne peut pas facilement maintenir le modèle mental architectural complet d'un système complexe et multi-couches dans sa mémoire active.
**Notre position : cela reste sous notre responsabilité.** Un client peut proposer un plan pour une fonctionnalité transverse, mais il n'est pas autorisé à générer et pousser le code de manière indépendante.
### Le triage en action
Désormais, quand un client comme Client B veut utiliser son IA de planification, la première question que nous posons lors du "pre-code check" est : **Est-ce local ou transverse ?**
Si un membre de Client B veut construire l'UI de sa nouvelle fonctionnalité de tchat, il peut le faire en 2 heures. Mais quand ce tchat doit gérer des connexions WebSocket en temps réel, persister les données de manière sécurisée vers la plateforme d'administration, et se synchroniser avec la base de données utilisateurs legacy, l'équipe BearStudio intervient.
Cette distinction est ce qui sauve le projet de l'effondrement sous le poids de la dette technique générée par l'IA. Elle donne au client le plaisir de construire des fonctionnalités visibles à grande vitesse, tandis que nous veillons silencieusement à ce que les fondations ne craquent jamais.

## Ce que cela change pour l'avenir
Ce modèle hybride avec Client B n'était pas une simple expérience ponctuelle ; c'était un aperçu de l'avenir de notre industrie. Nous avons découvert que lorsque nous cessons de lutter contre le désir du client de coder, nous débloquons un gain d'efficacité massif.
- **Ils se sentent autonomes :** Ils peuvent modifier la couleur d'un bouton ou ajouter un champ texte en 10 minutes sans nous payer une heure de travail.
- **Nous restons concentrés :** Libérés des modifications UI triviales, les développeurs se concentrent uniquement sur l'architecture de haut niveau et la logique complexe (le travail qui nécessite réellement une expertise humaine).
Nous entrons dans une ère où notre valeur ne se mesure plus au volume de code que nous écrivons, mais à la **stabilité du système que nous organisons**.
## "S'adapter ou disparaître"
Abordons le sujet qui fâche. Est-ce que cela signifie que les clients finiront par tout "vibe coder" eux-mêmes, nous laissant sans emploi ?
La réponse est un **"Non"** catégorique.
Si des outils comme ChatGPT ou Claude permettent à un fondateur de construire un prototype en 2 heures, ils ne résolvent pas la complexité d'un business qui passe à l'échelle.
**Tout le monde ne veut pas coder.** La plupart de nos clients sont des experts métier, pas des ingénieurs. Client A a apprécié l'exercice, mais il voulait finalement nous confier les clés pour se concentrer sur son business.
**Le "vibe coding" a un plafond.** C'est efficace pour une fonctionnalité, mais ça devient vite le chaos. Comme nous l'avons vu avec Client B, sans "guardrails", l'IA génère de la dette technique à la vitesse de la lumière.
Nous ne vivons pas une disparition. Nous vivons une **accélération**. La "valeur" que nous apportons ne réside plus dans la connaissance de la syntaxe d'une boucle for en Java. Elle réside dans le fait de savoir où placer cette boucle pour qu'elle ne fasse pas crasher le serveur pendant le Black Friday.
## Conclusion
Nous n'avons pas de boule de cristal, mais nous avons une direction.
Chez BearStudio, nous apprenons en continu. Nous adaptons nos pratiques, nos outils, et notre posture.
Ce que nous savons, en revanche, est simple :
**Les clients qui réussiront seront ceux qui vont vite.**
**Les agences qui réussiront seront celles qui permettent d'aller vite... sans casser le système.**
Alors, que vous ayez une idée, un prototype en 2 heures, ou une équipe prête à coder avec nous : venez, construisons la suite ensemble. Plus vite.
Nous transformerons cette énergie en produit robuste, scalable et réel.
## Pour aller plus loin
Envie d'approfondir le sujet de l'IA côté technique ? Jetez un œil à notre article :
- [Découvrir le MCP : une nouvelle approche pour vos agents IA](/fr/blog/articles/decouvrir-le-mcp-une-nouvelle-approche-pour-vos-agents-ia)
Plutôt curieux de nos collaborations et de nos retours d'expérience client ? Voici deux études de cas à découvrir :
- [Étude de cas UX : Cuisinez pour bébé](/fr/blog/articles/etude-de-cas-ux-cuisinez-pour-bebe)
- [Lea English : étude de cas](/fr/blog/articles/lea-english-etude-de-cas)
---
### IA & Client : les "Prototypeurs"
URL: https://www.bearstudio.fr/fr/blog/articles/ia-et-client-les-prototypeurs
Date: 2026-04-29
Ce n'est pas arrivé au cours d'une confrontation tendue en salle de réunion mais juste une notification Slack, un mardi comme un autre.
Nous avions estimé des tickets pour un client (que nous allons appeler « Client A »). Certains, comme la création d’un tchat directement intégré dans l’application, ont été identifiés comme du « travail conséquent ». Autrement dit, ces fonctionnalités demandaient du temps, des tests et un budget conséquent. Puis, on a vu la fameuse notification dans le canal.
Client A a expérimenté de son côté une version de l'application comme projet annexe. Il a partagé l'image d'un tchat entièrement fonctionnel avec un indicateur de saisie, accompagnée du message suivant :
> Par curiosité, j'ai testé la création d'un tchat hier. Voici le résultat en moins de 2 heures.
Pour une équipe de développement, voir une fonctionnalité estimée à plusieurs jours de travail apparaître en « moins de 2 heures » peut provoquer un moment de panique. Sommes-nous trop lents ? Notre expertise est-elle en train de devenir obsolète ? Même notre canal interne s'est animé : « Attends, est-ce qu'on utilise suffisamment ces outils ? Est-ce qu'on est en retard ? »

Mais Client A ne cherchait pas à nous piéger. Il ne nous demandait pas de copier-coller aveuglément une génération IA. En réalité, nous n'avons même jamais vu son code, seulement l'interface. Son message était en fait une invitation : il avait confiance en notre capacité à construire une application robuste et maintenable, mais il souhaitait nous pousser à exploiter cette même vitesse brute pour accélérer le processus.
## Client A n'est pas une exception. Il est la nouvelle norme.
Depuis l'arrivée de l'IA générative, nous observons un changement dans la manière dont les clients interagissent avec nous.
Ils ne sont plus seulement des « prescripteurs » ; ils deviennent des « créateurs ».
Certains, comme Client A, utilisent l'IA pour prototyper des visions qu'ils souhaitent nous voir industrialiser.
D'autres vont plus loin et veulent « vibe coder » avec nous, produire des fonctionnalités en temps réel tout en attendant de nous que nous garantissions la stabilité de l'ensemble.
Chez BearStudio, nous avons compris que nous ne pouvions pas ignorer cette évolution. Nous devions passer du rôle de « constructeurs » à celui de « garants ».
**Dans ce premier article, je souhaite montrer comment nous adaptons notre modèle de service à des clients qui codent parfois plus vite que nous, et pourquoi ils ont malgré tout plus que jamais besoin de nous.
Un second article suivra prochainement pour explorer un scénario qui va encore plus loin.**
## Le prototype « fantôme » : de gardiens à garants
Pour comprendre pourquoi cette interaction avec Client A a été un tournant, il faut revenir à la manière dont nous (et toute l'industrie) fonctionnions encore il y a deux ans.
### L'ancien modèle : le jeu de la « discovery »
Avant l'IA, lorsqu'un client souhaitait une fonctionnalité complexe comme un système de tchat, on jouait à une sorte de téléphone arabe. Comme dans ce jeu où un message est chuchoté de personne en personne et se déforme progressivement, l'idée initiale du client évoluait, perdait en clarté ou se transformait au fil des intermédiaires (Product Owner, Designer, Développeur). Chaque étape impliquait une interprétation, avec son lot de malentendus et de dérives par rapport à la vision d'origine.
C'était un processus conçu pour limiter les risques, mais il était lent.
Si un client arrivait avec son propre code, nous étions les « gardiens ». Nous regardions généralement ses tentatives amateurs, sourions poliment, les mettions de côté, puis réécrivions tout depuis zéro. Nous facturions le « quoi » (la fonctionnalité) et le « comment » (le code).
### Le basculement : l'incident Client A
Puis est arrivé le message Slack de Client A. Il ne s'était pas contenté de décrire le tchat ; il l'avait construit.
Lorsqu'il nous a proposé de nous montrer sa « plateforme admin » et le tchat qu'il avait développé en moins de 2 heures, il était en réalité un peu inquiet. Il plaisantait en disant qu'il ressentait « une grosse pression », car il savait que son code n'était pas de niveau professionnel.
C'est à ce moment-là que notre perception a changé. En interne, la réaction a été brute :
> Si un client peut générer une interface en une pause déjeuner, que sommes-nous en train de facturer ?
Mais lors de l'échange, la dynamique s'est inversée. Client A n'a pas dit : « J'ai fait votre travail. »
Il a dit : « Je peux vous montrer le reste, et vous pourrez me dire à quel point l'IA a probablement mal fait les choses. »
Il ne voulait plus que nous construisions le tchat. Il avait déjà « construit » la vision.
**Il voulait que nous la professionnalisions.**
### Le futur : le prototype EST la spécification
Cette expérience nous a forcés à accepter une nouvelle réalité : le « prototype fantôme » n'est pas un concurrent, c'est la spécification ultime.
Au lieu de passer des jours sur des user stories abstraites (« En tant qu'utilisateur, je veux voir un indicateur de saisie »), nous regardions simplement son écran. L'ambiguïté disparaissait.
- **Avant** : nous estimions 10 jours pour comprendre le besoin et le construire.
- **Aujourd'hui** : nous estimons 5 jours, dont 0 % consacré à deviner, et 100 % dédié à l'architecture, à la sécurité et à l'intégration, le tout accéléré par l'usage de l'IA dans le code.
Le code généré par l’IA fonctionnait pour un prototype, mais ne couvrait pas toujours les exigences d’un environnement de production (robustesse, sécurité, passage à l’échelle) ni l’ensemble de nos bonnes pratiques.
Et c’est normal : ce n’était pas son rôle.
Sa vraie valeur était ailleurs : nous permettre de sauter la phase de « discovery » pour aller directement à l’« engineering ».

## Comment cela nous prépare
C'est l'avenir de notre métier. Les clients ne viendront plus seulement avec des idées, mais avec des prototypes fonctionnels (mais imparfaits). Notre proposition de valeur évolue. Nous ne sommes plus ceux qui révèlent la magie du code (l'IA s'en charge désormais). Nous sommes ceux qui apportent la certitude de l'ingénierie.
**Nous passons du rôle de « constructeurs » à celui de « garants » : les experts capables de transformer une expérimentation excitante et risquée de 2 heures en un produit stable, fiable et rentable.**
Mais le cas de Client A reste relativement simple. Il développe dans son environnement, et nous dans le nôtre. Les deux codebases ne se croisaient jamais.
Que se passe-t-il lorsque le client ne veut plus seulement vous montrer la direction, mais souhaite conduire avec vous ?
On entre alors dans un second scénario, plus disruptif. Nous voyons émerger des équipes techniques qui ne se contentent plus de prototyper avec l'IA : elles livrent des fonctionnalités. Elles ont des budgets serrés, des délais agressifs, et une philosophie qui effraie les CTO traditionnels : le « vibe coding ».
Elles ne veulent pas que nous reconstruisions tout.
Elles veulent coder avec nous.
**Dans le prochain article, je détaillerais ce nouveau modèle de co-construction, ses risques, et les "guardrails" que nous avons mis en place pour éviter que la vitesse ne se transforme en chaos.**
## Pour aller plus loin
Envie d'approfondir le sujet de l'IA côté technique ? Jetez un œil à notre article :
- [Découvrir le MCP : une nouvelle approche pour vos agents IA](/fr/blog/articles/decouvrir-le-mcp-une-nouvelle-approche-pour-vos-agents-ia)
Plutôt curieux de nos collaborations et de nos retours d'expérience client ? Voici deux études de cas à découvrir :
- [Étude de cas UX : Cuisinez pour bébé](/fr/blog/articles/etude-de-cas-ux-cuisinez-pour-bebe)
- [Lea English : étude de cas](/fr/blog/articles/lea-english-etude-de-cas)
---
### Retour d’expérience : travailler depuis l’autre bout du monde
URL: https://www.bearstudio.fr/fr/blog/articles/travailler-depuis-l-autre-bout-du-monde
Date: 2026-04-16
L’année dernière, j’ai eu l’opportunité de partir deux semaines au Vietnam dans un cadre privé. L’idée n’était pas de prendre des vacances mais bien de télétravailler depuis l’étranger, avec une organisation pensée pour rester aligné avec mon équipe et avec mon entreprise en France.
Mon objectif était simple : voir s’il était possible de concilier travail efficace, décalage horaire et découverte d’un pays, sans sacrifier la qualité des échanges et du travail, ni le plaisir d'être sur place.
---
## Décalage horaire : le vrai défi
La première chose évidente à prendre en compte dans ce genre de projet, c’est le décalage horaire, dans mon cas il y avait 6 heures. Il faut donc réfléchir à aménager ses journées et ses horaires de travail pour essayer d’être le plus possible synchronisé avec son équipe en France.
Au Vietnam, je travaillais de **13h à 20h**.
Cela correspond à **7h - 14h en France**, ce qui permettait :
- d’avoir **2h de focus seul**, l’équipe française commençant à 9h
- d’avoir **5h en commun** avec mon équipe de travail
- d’assister aux **réunions importantes**
- de profiter du **matin et du soir pour visiter**
Par chance, mes réunions importantes étaient toutes le matin, je n’ai donc pas eu d'aménagement particulier à faire à ce niveau-là. Mais c’est un point essentiel à anticiper :
- Avez-vous des réunions à des horaires contraignants ?
- Sont-elles obligatoires ?
- Sont-elles adaptables ? Ou est-ce à vous d'aménager votre emploi du temps ?
> Exemple : une réunion à 15h en France correspond à 21h au Vietnam.
On peut imaginer qu’une réunion avec trois ou quatre collaborateurs peut être replanifiée exceptionnellement, alors qu’une guilde mobilisant des dizaines de personnes non.
### Les 2 heures seul : contrainte ou opportunité ?
Les 2 heures seul en début de journée peuvent apparaître comme une contrainte, mais c’était en réalité **un atout majeur** pour moi.
Bien sûr, cela me permettait de **rester concentré** pendant une longue plage horaire et de faire avancer mes sujets, mais il y avait d’autres avantages.
Les POs du projet avaient tendance à commencer leur journée plus tôt que l’équipe de développement. Cette plage de 2 heures me permettait donc d’**échanger beaucoup plus facilement** avec eux, avant qu’ils ne soient débordés.
Un autre aspect positif était ma **disponibilité**. À l’époque, nous venions de mettre en production l’application, nous étions donc dans une période de stabilisation. Savoir que j’étais connecté dès 7h et disponible pour corriger des retours ou des situations d’urgence rassurait l’équipe.
Cependant, cet avantage demande de l’**anticipation**. Si je me retrouvais bloqué dès le début de ma journée, je devais attendre 2 heures avant de pouvoir solliciter quelqu’un.
👉 Tous les jours, avant de partir, je faisais donc une rapide analyse pour m’assurer d’avoir tout ce qu’il me fallait pour le lendemain.
### Une journée bien structurée
Ainsi, mes journées s’organisaient de la manière suivante :
- **Matin** : visites, découvertes et déjeuner
- **13h - 20h** : travail
- **Soirée** : restaurants et balades
Je respectais mes 7 heures de travail par jour, sans pour autant délaisser l’aspect touristique.
👉 Ce n’était pas du “travail entre deux visites”, mais une vraie **journée structurée**.
---
## Matériel et conditions de travail
### D’un hôtel à un restaurant en bord de mer
Pour rester fiable à distance, il faut anticiper deux choses : une **connexion**… et un **plan B**.
Concrètement ça veut dire :
- Sélectionner des hôtels avec **Wi-Fi**
- Acheter une carte SIM vietnamienne avec **4G illimitée** (facile à obtenir et avec une excellente couverture)
Ainsi, je pouvais passer en partage de connexion si le Wi-Fi faiblissait.
Cela peut paraître évident, mais c’est un point important à étudier pour être sûr de ne manquer aucune réunion et vous éviter l’anxiété de la coupure internet.
Sans oublier la liberté qu’offre l’assurance d’une connexion stable, vous pourriez même finir par travailler dans un restaurant au bord de la mer… 👀
### Qu’est-ce qu’on emmène ?
Le matériel est un point clé, mais en avion on ne peut pas tout emporter. Chaque gramme compte, donc plus que jamais je me suis demandé : **de quoi ai-je VRAIMENT besoin ?**
Voici ce que j’ai emmené :
- **PC portable et son chargeur** - évidemment
- **Une souris sans fil légère** - j’ai pris l’habitude de travailler à la souris
- **Un hub** - plus petit que celui que j’utilise d’habitude
- **Un casque compact avec réduction de bruit** - pratique pour travailler dans des lieux bruyants et rester focus
- **Un sac adapté** - on n’y pense pas tout de suite mais réfléchir au soin du matériel et à son propre confort est important
Cette liste reflète ce dont j’ai **personnellement** besoin pour travailler, mais en fonction de **votre ordinateur** ou de **vos habitudes**, elle peut varier : peut-être que vous ne prendriez pas de souris ou de hub, peut-être que vous prendriez un écran portable en plus, bref tout est possible.
👉 Le plus important : **ne partez pas chargé, partez optimisé.** Chaque objet doit avoir une utilité réelle et régulière, pas juste être là “au cas où”.
---
## Travailler seul… mais en équipe
On a vu le décalage horaire, on a vu le matériel et les conditions de travail, mais il reste un point important : votre équipe. Parce que oui, vous êtes seul à l’autre bout du monde mais il faut continuer à faire avancer le projet collectivement. Alors, comment on fait ?
Déjà il faut anticiper la distance. Dans mon cas, j'avais déjà une partie de mon équipe qui travaillait depuis le Maroc, donc nous avions pris l’habitude et mis en place les process pour travailler avec des gens sans être dans les mêmes bureaux.
La distance n’a donc pas été un défi à relever pour moi, mais c’est une composante à prendre en compte en fonction de votre situation.
Le vrai enjeu pour moi c’était le décalage horaire.
Et le point le plus important pour que tout se passe au mieux, c’est la **communication**.
Voici quelques exemples de choses que j’ai mis en place :
- Annoncer clairement mes **horaires de travail** (locales et françaises)
- Mettre tous les jours un message pour dire “**Bonjour**” quand je commence à travailler
- Et mettre un message pour dire “**Au revoir**” quand j’arrête de travailler
- Renseigner mon **agenda** pour éviter les surprises
- Caler les **réunions** dans les fenêtres communes
- Basculer sur un mode **communication asynchrone** sur certains sujets
🎯 Objectif : être **loin géographiquement**, mais rester **proche de l’équipe**.
---
## Une bonne expérience ?
Une telle expérience met en lumière de nombreux points positifs :
- De **longues plages de travail** concentré où j’ai pu faire avancer mes sujets
- Une **motivation “naturelle”** liée au changement d’environnement
- Un **vrai équilibre** entre tourisme le matin et travail l’après-midi
- Entretenir une **discipline** et une **rigueur personnelle**
Mais il ne faut pas tout idéaliser non plus :
- La **fatigue** liée au décalage horaire et au rythme soutenu des journées
- L’**envie de tout faire** (notamment en termes de visites), il faut savoir aussi se reposer pour ne pas craquer
- Une **logistique permanente** à gérer
- Besoin d’une grande **auto-discipline**
👉 En réalité, tout repose sur un **état d’esprit** : ce n’est pas du “travail en vacances”, c’est du **travail dans un autre cadre**.
---
## Bilan et conseils
Même si l’expérience a été fatigante, elle reste extrêmement positive. Elle m’a permis de : découvrir un pays, continuer à travailler efficacement et me prouver ma capacité d’adaptation et mon auto-discipline.
👉 Je recommande vivement l’expérience.
Mais, vous l’aurez compris, tout cela ne se fait pas sans réflexion et anticipation. Voici donc, selon moi, les **conseils les plus importants à retenir** :
- Vérifier et cadrer l’accord organisationnel avec votre entreprise
- Prendre une carte SIM avec 4G illimitée pour éviter tout problème
- Définir des horaires de travail fixes et les respecter
- Réduire son matériel au strict nécessaire
- Investir dans un bon casque compact à réduction de bruit
- Penser son sac à dos comme un bureau portable
- Ne pas hésiter à poser quelques jours de congés pour profiter pleinement
Travailler à l’autre bout du monde sans perdre en efficacité, **c’est possible**.
Et surtout : **je le referai.**
---
### Déployer Start UI Web sur Upsun
URL: https://www.bearstudio.fr/fr/blog/articles/deployer-start-ui-web-sur-upsun
Date: 2026-03-31
## Avant-propos
Dans le cadre d'une exploration des solutions de déploiement modernes,
j'ai testé [Upsun](https://upsun.com/), une plateforme PaaS récente proposée par les
créateurs de Platform.sh.
L'objectif était double :
- **Évaluer Upsun comme alternative à Clever Cloud**, que j'utilise déjà,
afin de comparer l'expérience développeur, la configuration et
l'ergonomie.
- **Tester un déploiement initial** ("from scratch") **sans connaissance
préalable d'Upsun ni expérience en devops**. La perspective adoptée est celle d'une développeuse découvrant l'outil.
Pour ce test, j'ai choisi de déployer notre outil maison [Start UI Web](https://start-ui.com/),
un starter d'application moderne basé sur React, Vite et Node.js, que nous utilisons régulièrement comme base de projets front-end. (Pour en savoir plus, vous pouvez lire dès maintenant notre [article de présentation Start UI](/fr/blog/articles/start-ui) !)
Cet article se veut volontairement pragmatique : il mélange **tutoriel pas
à pas** et **retour d'expérience**, avec ses points forts, ses frictions et
ses limites.
---
## Étape 1 : Création d'un compte sur Upsun
Un compte doit être créé sur la plateforme Upsun via la console
officielle.
_⚠️ Ce tutoriel a été réalisé sur Upsun v3.3.45 !_
Inscription via email ou fournisseur tiers (GitHub, Google, etc.).
Une période d'essai gratuite de 15 jours est proposée. Elle permet d'accéder à un seul projet pendant cette durée limitée,
avec les ressources suivantes : 1 organisation (avec 1 projet et 2 running environments) et un nombre de users illimités.
À la fin de l'essai, votre projet sera suspendu jusqu'à ce que vous ajoutiez un mode de paiement valide à votre compte.
Une fois connecté, il est donc nécessaire d’activer un projet afin de pouvoir procéder aux déploiements.
Jusque là, une interface prometteuse, et un début de mise en place classique !
---
## Étape 2 : Fork / Init du dépôt Start UI Web v3 et configuration locale
Le dépôt officiel Start UI Web v3 peut être forké depuis le [repository GitHub de BearStudio](https://github.com/BearStudio/start-ui-web).
Ce fork permet de disposer d’une copie du projet sous son propre compte GitHub.
Le projet forké doit ensuite être cloné en local afin de vérifier que l’installation fonctionne correctement avant tout déploiement.
La documentation officielle de Start UI Web précise que le projet nécessite une version récente de Node.js ainsi que l’utilisation de [pnpm](https://pnpm.io/) comme gestionnaire de dépendances.
Un fichier d’environnement local peut être généré à partir du fichier d’exemple fourni afin de permettre un démarrage en local.
Alternativement, pour initialiser un projet, on peut utiliser `pnpm create start-ui -t web myApp`. Il est ensuite impératif de pousser le projet sur un dépôt GitHub pour qu'il soit éligible au déploiement (les deux solutions ont été testées et fonctionnent aussi bien l’une que l’autre !).
---
## Étape 3 : Synchronisation d'un dépôt GitHub avec Upsun
Upsun permet de synchroniser directement un dépôt GitHub à l’aide d’une intégration native.
Il convient d’ajouter une intégration GitHub depuis les paramètres du projet Upsun, puis de sélectionner le dépôt cloné ou créer de Start UI Web.
Cette intégration permet à Upsun de déclencher automatiquement un déploiement à chaque modification poussée sur la branche configurée.
Dans ce mode de fonctionnement, les déploiements sont pilotés par GitHub et non par un push direct vers une remote Upsun. Il est également possible de configurer le déploiement manuel et de désactiver l'automatisation.




C’est à partir de cette étape que les choses se sont corsées :(
Une fois que j’ai sélectionné l’option “Sync Github repository” puis validé sur Github le choix du repo, j’ai été redirigé vers Upsun avec une erreur.
J’ai recommencé 2 fois l’étape pour y arriver, utiliser deux repos différents avant de retenter celui de Start UI, pas d’explication particulière mais c’est passé ! 🤷🏼♀️

---
## Étape 4 : Configuration initiale du projet Upsun
Une fois le projet lié à Upsun, une initialisation doit être effectuée afin de générer les fichiers de configuration nécessaires.
Cette étape permet de :
- définir la technologie utilisée (Node.js),
- ajouter les services nécessaires comme une base de données,
- générer automatiquement un dossier `.upsun` à la racine du projet,
- créer un fichier de configuration principal et un fichier `.environment`.
À ce stade, la configuration générée peut être conservée telle quelle.
Un premier déploiement est ensuite déclenché après un commit et un push.
J’ai supposé qu’il est normal que ce premier déploiement échoue ou ne produise aucun build fonctionnel, car les instructions spécifiques à l’application ne sont pas encore définies.




J’ai tenté d’utiliser l’option de génération assistée par IA pour l’initialisation de la configuration du projet mais ça a été un échec. J'espérais une solution miracle pour un déploiement en un clic. Cependant, ne maîtrisant ni le code, ni sa conception, ni sa raison d'être, j'ai préféré repartir d'une configuration manuelle. J'ai dû la revoir plusieurs fois avant de comprendre les champs absolument nécessaires (les hooks, la commande de start, les variables d’environnements,..).
---
## Étape 5 : Récupération des URLs de l’application et de la base de données
L’URL publique de l’application est visible directement dans l’interface Upsun, dans la section dédiée aux environnements et aux routes.
Les informations de connexion à la base de données sont accessibles via les relations Upsun.
Ces relations permettent d’obtenir l’hôte, le port, le nom de la base, l’utilisateur et le mot de passe nécessaires à la construction de l’URL de connexion.
Ces informations sont indispensables pour compléter la configuration de l’application mais ne sont pourtant pas facilement accessibles. Il est nécessaire de chercher un peu dans la documentation pour trouver comment accéder aux paramètres d'Upsun et les vérifier.

---
## Étape 6 : Personnalisation du fichier de configuration Upsun
Le fichier de configuration situé dans le dossier `.upsun` doit être adapté aux besoins de Start UI Web.
### Variables d’environnement
Les variables sensibles ne doivent pas être stockées en clair dans le dépôt lorsque cela est évitable comme par exemple dans le fichier de configuration Upsun qui sera push sur la branche (et là je ne parle pas du tout par expérience 😇…).
Upsun permet de définir des variables par environnement directement depuis l’interface de gestion, mais elles sont à remplir une par une !
Le fichier `.environment`, quant à lui, est utilisé par Upsun pour connecter automatiquement l’application aux services déclarés.
Il n’a pas vocation à contenir l’ensemble des variables applicatives et ce n’est pas non plus une simple copie du `.env`. Pour Start UI j’ai laissé les variables d’environnement liées à la base de données qui ont été automatiquement ajoutées.
J’ai ensuite mis les variables d’environnement suivantes dans l’interface :
- la chaîne de connexion à la base de données,
- les secrets d’authentification,
- les paramètres liés aux sessions,
- les variables utilisées par Vite pour l’interface,
- l’environnement d’exécution.
Le menu pour renseigner les variables est accessible depuis les options du menu principal (que je n’ai pas arrêté de chercher en onglet à côté de l’overview 😅).



### Hook de build et de déploiement
Les hooks Upsun doivent être configurés afin d’installer les dépendances, construire l’application et exécuter les scripts nécessaires au bon fonctionnement de Start UI Web.
Le **hook de build** est utilisé pour installer les dépendances et générer le build de production.
Le `–ignore-scripts` lors de l’installation reste important pour éviter la configuration de husky et des hooks git qui viennent polluer les logs de pleins d’erreurs.
Dans notre cas :
```bash
npm i -g pnpm npm-run-all
pnpm install --ignore-scripts
pnpm postinstall
pnpm build
```

Le **hook de déploiement** permet d’exécuter les scripts liés à l’initialisation de la base de données.
Dans notre cas : `pnpm db:init`

Ces hooks sont exécutés automatiquement par Upsun à chaque déploiement.
### Lancement de l’application
Ne pas oublier de modifier la commande de la partie `web > commands > start` : `pnpm start`.

Après de multiples tentatives, ce sont normalement les seules commandes nécessaires.
---
## Étape 7 : Commit, push et déploiement
Une fois la configuration finalisée, les modifications doivent être ajoutées au dépôt Git et poussées sur la branche suivie par Upsun.
Si une intégration GitHub est utilisée, le simple fait de pousser sur le dépôt distant déclenche automatiquement le déploiement sur Upsun (`git push` déploie sur Upsun, et `upsun push` pousse également sur GitHub). Sans intégration, le push doit être effectué vers la remote Upsun.
Le premier déploiement complet peut prendre plusieurs dizaines de minutes ⏱️.
---
## Étape 8 : Accès à l’application déployée
Après la fin du déploiement, l’application est accessible via l’URL fournie par Upsun.
Un court délai supplémentaire peut être nécessaire lors du premier chargement, notamment si la base de données est en cours d’initialisation. (+3min ⏱️)


---
## Commandes, conseils et remarques complémentaires
### Consultation des logs
L’interface Upsun affiche principalement les logs liés aux phases de build et de déploiement (mais ils mériteraient un scroll automatique pour garder les logs les plus récents à l’écran).
Pour consulter les logs d’exécution de l’application, il est nécessaire d’utiliser la commande dédiée via l’outil en ligne de commande Upsun : `upsun log` (`upsun log app`, `upsun log deploy`, etc.).
Il est également possible d’accéder à la machine en SSH afin d’inspecter les fichiers de logs générés par l’application mais c’est dommage de pas pouvoir les voir depuis l’interface.
### Connexion en SSH
Upsun fournit un accès **SSH** directement depuis son interface.
Cet accès permet de diagnostiquer les problèmes, consulter les fichiers générés ou vérifier l’état de l’application en cours d’exécution.

### Ports et gestion des variables d’environnement
Upsun ne permet pas l’utilisation de ports **statiques** exposés manuellement.
Les ports sont attribués **dynamiquement** et gérés automatiquement par la plateforme.
Cela n’impacte pas le fonctionnement de Start UI Web, qui s’appuie sur les mécanismes standards de déploiement fournis par Upsun.
L’**onglet « variables d’environnement »** de l’interface Upsun permet de définir des valeurs spécifiques à un environnement donné.
Les variables définies dans le fichier de configuration ne sont pas dupliquées automatiquement dans cette interface, car elles répondent à des usages différents mais c’est ici que je m’attendais à les retrouver.
Les variables **statiques** définies dans le fichier de configuration sont versionnées et **communes** à tous les environnements, tandis que celles définies via l’**interface** peuvent **varier** selon les **contextes** (production, staging, etc.).
---
## Retour d'expérience et pistes d'améliorations
### Problèmes d’interface et d’ergonomie
- Le temps de déploiement affiché dans l’interface est de **6 minutes**, alors qu’en réalité il dépasse souvent **20 minutes**, ce qui est un peu frustrant 😅.
- L’interface n’est pas spécialement intuitive, le bouton “Redéployer” manque de visibilité, des options sont répétitives et se retrouvent dans plusieurs sous menus, l’accès à certains onglets n’est pas clairement indiqué, et il y a pas mal de menus, boutons et tabs aux styles différents.
- Les modales sont assez peu ergonomiques et rendent l’expérience moins fluide :
- devoir cliquer sur “Options” puis sur un bouton,
- ou passer par le bouton de statut pour effectuer une action.
- Les **options situées dans la colonne de gauche** ne sont pas très bien mises en avant et assez peu lisibles.

- Certaines cards ou éléments ont un effet hover alors qu’elles ne sont pas cliquables, ce qui crée de la confusion.

- Il y a **trop de boutons “Options”**, souvent redondants et proposant les mêmes actions à plusieurs endroits.
- La sélection de l’environnement et de la branche n’est pas intuitive, et aucune branche n’est sélectionnée par défaut.
- Tous les tooltips s’affichent en même temps sur les pages contenant des graphes, ce qui surcharge l’interface et peut nuire à la compréhension.
### Variables d'environnement
- Les variables d’environnement utilisées dans le `config.yaml` ne sont pas clairement retranscrites dans l’interface, et le menu dédié est difficile d’accès.
- L’ajout par l’interface des variables d’environnement une par une est frustrant.
- Une fois une variable d’environnement créée, il est impossible d’en modifier le nom, ce qui est contraignant.
### Déploiement & erreurs
- Le bouton permettant de créer une nouvelle branche affiche “Cannot create a new branch” sans fournir d’explication, ce qui rend le problème difficile à diagnostiquer (à ce jour je ne sais toujours pas 😅).
- En naviguant entre les onglets, il arrive qu’un problème de fetch fasse disparaître l’historique des déploiements, ce qui est perturbant parce que d’un coup il n’y a plus rien.
### Logs et observabilité
- La consultation des logs via l’interface est peu pratique :
La modale comporte un scroll interne en plus du scroll de la page,
il n’y a pas de scroll automatique lorsque de nouveaux logs apparaissent,
et pour consulter les logs applicatifs, il faut passer par SSH + `cat` ou utiliser `upsun log`, ce qui n’est pas vraiment l’idéal.
### Facturation et paiement
- Il est possible de ne pas renseigner de moyen de paiement, tout en recevant malgré tout une facture, ce qui est incohérent mais permet de se projeter sur les coûts.
- Le dark mode est à revoir, notamment la modale de paiement dans l’onglet Billing Details, qui fait mal aux yeux !

- Certains utilisateurs doivent confirmer leur identité avec une carte bancaire, tandis que d’autres non, sans logique apparente (j’ai fait parti de la seconde catégorie 😝).
- Il est impossible de consulter le moyen de paiement enregistré au moment de l’identification (à vérifier si c’est bien précisé qu’ils ne sauvegardent pas les informations).
### Autres remarques UI
- Dans l’onglet Backup, le bouton “i” situé sous le titre n’est pas clair.
- Le bouton “Manage schedule” manque de cohérence visuelle avec le reste de l’interface et n’est pas esthétique.
---
## Conclusion
Déployer Start UI Web v3 sur Upsun est tout à fait possible et fonctionne correctement une fois la configuration en place.
Cependant, **la courbe d’apprentissage est réelle**, notamment pour une développeuse junior ou quelqu’un découvrant Upsun sans accompagnement.
Upsun propose une base technique solide, mais son **ergonomie et sa DX gagneraient à être simplifiées**, en particulier sur :
- la gestion des variables
- la lisibilité des erreurs
- l’accès aux logs
En tant qu’alternative à Clever Cloud, Upsun mérite clairement d’être testé, mais demande aujourd’hui un investissement initial qui m’a semblé assez important.
Si vous souhaitez aller plus loin, vous pouvez découvrir nos librairies open-source _made-in-BearStudio_ : [UI-State](/fr/blog/articles/pourquoi-on-a-cree-ui-state) et [Ficus UI](/fr/blog/articles/ficus-ui-ui-simple-et-composable-pour-react-native).
---
### Pourquoi on a migré de WordPress vers Astro
URL: https://www.bearstudio.fr/fr/blog/articles/pourquoi-on-a-migre-bearstudiofr-de-wordpress-vers-astro
Date: 2026-03-17
_En février 2026, on a finalement franchi le pas : bearstudio.fr tourne désormais sous Astro. Voici le retour d'expérience complet d'une refonte de ~200 pages, une trentaine de jours de travail collectif, et une vraie fierté d'équipe. Un article qui intéressera particulièrement les équipes tech, les développeurs React et plus globalement front-end, et quiconque envisage de s'affranchir de WordPress._
---
## Un peu d'histoire : trois versions, trois époques
Le site de BearStudio a connu trois vies.

La première version du site développée en 2016. Cette capture est issue de
Internet Archive.
La première version, dont il existe [une archive datant de novembre 2016](https://web.archive.org/web/20161107063014/http://www.bearstudio.fr/), tournait sur **GravCMS**, un CMS à base de fichiers, sans base de données. En [novembre 2019](https://web.archive.org/web/20191117075057/https://www.bearstudio.fr/), on est passés à WordPress, la solution évidente à l'époque, celle qui "fonctionnait". Et pendant plus de six ans, ça a tourné. Jusqu'en février 2026, où on a tout migré vers [Astro](https://astro.build/).

Deuxième version du site, mis en production en novembre 2019
Ce n'est pas une décision prise à la légère. C'est le résultat d'années de frictions accumulées, de dette technique qui s'entassait, et de l'envie de reprendre la main sur notre propre outil.
---
## Ce qui a fini par nous convaincre de quitter WordPress
WordPress, c'est une solution qui a fait ses preuves. Mais au fil du temps, plusieurs problèmes sont devenus impossibles à ignorer.
### La Developer Experience, une vraie galère
Le workflow était pénible. On avait les sources sur GitHub qu'il fallait déployer sur l'instance WordPress. Lent, fastidieux, source d'erreurs. Pour une agence de développement dont c'est le site vitrine, c'est difficile à accepter sur le long terme. On entassait de la dette technique sur un outil qu'on ne maîtrisait pas complètement.
### Les performances, un plafond de verre
WordPress fait du rendu côté serveur par défaut. Résultat : des pages qui peuvent mettre du temps à charger, des [scores Lighthouse](/fr/blog/articles/checklist-seo-technique) décevants, un ressenti utilisateur en dessous de ce qu'on attendait pour notre propre site. Passer à de la génération statique avec Astro a changé la donne de façon drastique.
### La sécurité, un risque permanent
Le code de WordPress est très répandu, ce qui en fait une cible de choix. Les mises à jour de sécurité s'enchaînent, les plugins peuvent introduire des vulnérabilités. Pour un site statique généré à la compilation, la surface d'attaque est quasi nulle. Et notre nouveau site est entièrement open source, consultable sur GitHub, une posture en accord avec nos valeurs et notre implication dans la communauté.
### Les coûts, un poste optimisable
On utilisait WP Engine pour l'hébergement : environ 300 $ par an. Aujourd'hui, on est sur un compte partagé qui couvre plusieurs de nos applications pour 20 $ par mois, répartis sur l'ensemble de nos projets. Bien plus rentable à l'échelle.
### Une stack qui n'évoluait plus avec nous
C'était aussi l'occasion parfaite de revoir nos offres à l'ère de l'IA. Nos processus de développement ont profondément évolué : on intègre aujourd'hui l'IA dans nos workflows et dans les projets qu'on accompagne. Autant que notre site vitrine le reflète clairement, pour les clients qui nous découvrent.
---
## Pourquoi Astro plutôt que Next.js, Nuxt ou Gatsby ?
On avait déjà de l'expérience sur d'autres solutions. J'avais notamment travaillé sur le site de Codeurs en Seine avec Gatsby, puis on avait migré ce même site vers Next.js avec ContentLayer pour la gestion des fichiers Markdown. C'était assez lourd et l'écosystème était assez passif, ContentLayer n'évoluait plus.
Astro s'est distingué sur plusieurs points :
**La gestion de contenu intégrée** : Astro permet de définir des schémas de contenu directement dans le code. Si un champ est manquant ou mal renseigné dans un fichier Markdown, le build plante avec un message d'erreur explicite. C'est un filet de sécurité extrêmement pratique au quotidien.
**Les performances par défaut** : Astro adopte une approche "zéro JavaScript côté client par défaut", ce qui favorise des sites ultra-rapides sans configuration particulière.
**La flexibilité des Astro Islands** : on peut intégrer des composants React, Vue ou Svelte uniquement là où c'est nécessaire, sans charger un framework entier pour toute la page.
On a choisi de ne pas utiliser de CMS headless (on avait d'ailleurs exploré [Outstatic](/fr/blog/articles/gerer-facilement-le-contenu-de-votre-site-avec-outstatic) par le passé). Tout le contenu est géré en fichiers Markdown ou MDX (pour les articles qui nécessitent des composants React embarqués). Simple, versionné avec le code, sans dépendance externe. Ce qui ressemblait à une contrainte est devenu un avantage : tout est au même endroit, tout le contexte est disponible, et avec l'IA, c'est une vraie force.
---
## Une refonte, pas juste une migration
La trentaine de jours nécessaires inclut bien plus que du développement pur. Voici comment le projet s'est réparti :

La veille concurentielle et le découpage des informations ont été une
majeure partie du temps pris pour ce nouveau site.
- **La réflexion en amont et la veille concurrentielle** pour définir la direction du nouveau site, j'ai effectivement passé pas mal de temps à voir ce qui se faisait ailleurs à l'international
- **La mise en place du socle technique** par [Grégoire](/fr/equipe/gregoire-protas) et [Noé](/fr/equipe/noe-tatoud)
- **Le développement et le design** portés principalement par [Ivan](/fr/equipe/ivan-dalmet) et moi
- **Le travail éditorial et SEO** pour ne rien perdre des acquis et affiner le message marketing

Beaucoup de réflexion sur le découpage des blocs du site.
Désormais, c'est toute l'équipe qui va pouvoir contribuer, que ce soit technique ou via des articles de blog.
### Un vrai travail éditorial
On est partis d'environ 200 pages, articles de blog, pages de prestations, membres de l'équipe, pages de contact, et on en a profité pour **retravailler le contenu marketing en profondeur** : fusion des catégories front-end et back-end sous un seul axe "développement web", ajout d'une catégorie "boost de projet" et d'une catégorie dédiée à l'IA. Ce n'était pas juste une migration technique.
### La partie la plus complexe : le système de traduction
Le défi technique le plus chronophage a été la gestion du multilingue. On voulait un site disponible en français et en anglais, on a déjà des clients internationaux et on est actifs dans la communauté open source et React. On accompagne aussi des startups et des équipes tech en tant que partenaire de développement ou dans un rôle proche de l'accompagnement CTO, et dans ce contexte, parler anglais couramment, y compris sur notre site, est indispensable.
Astro ne fournit pas de solution built-in complète pour les traductions (mais fournit quelques solutions minimales). Il a fallu construire une solution custom, avec des subtilités à gérer notamment autour des collections mais également des **Astro Islands** : quand on passe des props dans des composants interactifs, il faut être vigilant pour ne pas alourdir inutilement le bundle envoyé au client.
### Le SEO, un chantier à part entière
On avait plusieurs années de travail SEO sur l'ancienne version. Hors de question de tout perdre. Un gros travail de mapping des URLs, de mise en place des redirections et de vérification des balises a été réalisé pour préserver les acquis.
---
## Les grands changements du nouveau site
### Un design repensé, une image de marque préservée
Ivan a fait un passage de design fort, tout en gardant notre identité visuelle. Les couleurs de BearStudio, le bleu et le jaune, sont toujours là, mais leur usage a été rationalisé. Sur l'ancien site, le jaune était omniprésent au point d'être "too much". Le nouveau design l'utilise de manière plus chirurgicale, là où il crée vraiment de l'impact.
### Des choix UX orientés humains et clarté
Le nouveau site met davantage en avant les personnes qui composent BearStudio. La navigation est plus claire, l'accès aux offres plus direct. On a aussi introduit une communication plus indirecte et mémorable via les "polaroids", un élément visuel qui crée de la personnalité sans surcharger la page.
La page blog illustre parfaitement cette évolution : plusieurs articles sont désormais immédiatement visibles, même sur mobile, ce qui n'était pas le cas avec l'ancien thème WordPress.
### Un site qui parle aussi aux clients internationaux
La version anglaise du site était une priorité. Se positionner sur la langue de Shakespeare nous ouvre des portes avec des clients et des communautés qu'on ne touchait pas suffisamment jusqu'ici. Et on ne va pas se le cacher, c'est aussi beaucoup plus simple aujourd'hui grâce à l'IA, on fait une passe rapide, on relit, et on a notre page.
---
## Ce qu'on a gagné au quotidien
**Performances** : le chargement est nettement plus rapide. La génération statique fait son travail, couplée à une [optimisation des images](/fr/blog/articles/optimiser-images-site-web) native dans Astro.
**Sérénité** : on a la main sur l'intégralité de la stack. Pas de plugin mystérieux, pas de mise à jour WordPress à la chaîne, pas de workflow de déploiement bancal. On écrit du code, on pousse sur GitHub, c'est en ligne (et on a même les prévisualisations des changements avant les mises en production, pratique pour tester).
**Maîtrise** : on n'a pas d'équipe marketing dédiée à la mise à jour du site. Avoir une stack qu'on connaît sur le bout des doigts, c'est ce qui rend tout ça viable et agréable au long terme.
---
## À qui recommander cette migration ?
Astro est un excellent choix pour **tout site majoritairement statique** : site vitrine, portfolio, blog, site d'agence. Si votre contenu est stable et que vous voulez des performances maximales sans sacrifier la flexibilité, Astro coche toutes les cases.
En revanche, si vous avez une grosse équipe non-technique qui doit mettre à jour le contenu au quotidien, l'absence d'interface CMS peut devenir un frein. Dans ce cas, une combinaison Astro + CMS headless (Sanity, Contentful, Directus…) sera plus adaptée.
**Un conseil** : ne réduisez pas la migration à un exercice technique. C'est l'occasion idéale de retravailler votre contenu, clarifier votre message et moderniser votre design. C'est ce qu'on a fait, et c'est clairement ce qui fait la différence.
---
## Et après ? Ce qu'on prépare pour la suite
La migration n'est pas une fin en soi. C'est une base saine sur laquelle on va continuer de construire.
### Du contenu qui reflète vraiment qui on est
L'objectif du site à terme, c'est d'être une vraie vitrine de BearStudio : qui on est, ce qu'on fait, et les humains derrière tout ça. Presque une base de données publique de nous-mêmes, un endroit où l'on rend accessible au public tout ce qu'on a en interne : nos technologies, notre façon de travailler, nos projets open source, comme [Start UI](/fr/blog/articles/start-ui).
Dans ce sens, on prépare plusieurs nouvelles sections. Une dédiée aux **événements**, pour savoir où retrouver la team BearStudio dans la vraie vie, que ce soit des meetups, des conférences ou des événements de la communauté React et open source. Une autre centrée sur les **technologies qu'on utilise** et sur nos contributions open source, pour documenter nos choix techniques et partager ce qu'on construit.
### L'IA, déjà dans le site
On a commencé à préparer le site pour l'ère des agents et des LLMs. Un fichier `llms.txt` est déjà en place à la racine, et tous les articles de blog sont accessibles en Markdown en suffixant `.md` ([exemple avec cet article](/fr/blog/articles/pourquoi-on-a-migre-bearstudiofr-de-wordpress-vers-astro.md)) à n'importe quelle URL. Le site est pensé pour être lisible aussi bien par des humains que par des IA.
Et en interne, on utilise **Claude Code** au quotidien pour construire les évolutions du site. L'IA n'est pas un sujet futur chez nous, c'est déjà dans nos outils.
### Les chantiers techniques en cours
Un point qu'on a mis de côté lors de la migration : les **Open Graph dynamiques**. Actuellement, les images de partage sont statiques. On est en train de réintégrer une génération dynamique, en s'appuyant sur la base qu'on avait développée pour le site de [Fork it! Community](https://www.forkit.community/). C'est un chantier court, mais qui aura un vrai impact sur la façon dont nos articles s'affichent quand ils sont partagés sur les réseaux.
---
## Merci
Un grand merci à toutes les personnes qui se sont impliquées dans ce projet, de près ou de loin : Grégoire, Noé, et un merci particulier à **Ivan** pour le design et les réflexions partagées sur le contenu.
---
### Étude de cas UX Cuisinez pour bébé
URL: https://www.bearstudio.fr/fr/blog/articles/etude-de-cas-ux-cuisinez-pour-bebe
Date: 2026-01-27
## À propos de Cuisinez pour bébé
L’histoire de _Cuisinez pour Bébé_ commence avec Clémence, une jeune maman passionnée de cuisine qui souhaitait offrir à son enfant une alimentation saine, simple et variée. Comme beaucoup de parents, elle s’est posé les questions essentielles :
##### Comment réussir la diversification alimentaire ? Comment préparer des repas équilibrés sans y passer des heures ?
Pour y répondre, elle commence par partager ses recettes maison sur un blog, qui devient rapidement un site WordPress structuré. Le succès est immédiat : les jeunes parents y trouvent des repères clairs, des idées concrètes et une approche décomplexée de la cuisine pour bébé.
Aujourd’hui, _Cuisinez pour Bébé_ rassemble plus de **1 800 recettes**, classées par **âge**, des **menus hebdomadaires** de **batch cooking**, ainsi qu’une multitude de conseils pratiques pour **accompagner** chaque étape de la diversification.
## Le défi / Le besoin
Avec plus de **150 000 visites mensuelles** et une communauté très active sur les réseaux sociaux, _Cuisinez pour Bébé_ s’est imposé comme une ressource incontournable pour les parents en quête de recettes simples et équilibrées pour leurs enfants.
Ce succès a cependant révélé un besoin clair : rendre l’expérience plus fluide, plus mobile et plus personnalisée. La majorité des utilisateurs consultait déjà le site depuis leur téléphone et exprimait le besoin d’accéder plus rapidement à leurs recettes, à leurs favoris et aux menus hebdomadaires directement depuis une application.
L’enjeu était donc de transposer l’expérience du site dans un format mobile intuitif, fidèle à l’univers existant, tout en intégrant des fonctionnalités clés : un modèle freemium, une navigation adaptée à l’âge de l’enfant et un accès simplifié aux menus de batch cooking.
L’application devait devenir une extension naturelle du site, au service du même objectif :
**accompagner les parents au quotidien dans la préparation des repas de leur bébé.**
## Notre rôle
Côté [BearStudio](/fr/), le projet est porté par une équipe dédiée dont la composition a évolué au fil du temps.
Équipe actuelle :
- 1 Lead UX/UI Designer
- 1 UX/UI Designer
- 1 Lead Développeur Full-Stack
Contribution passée :
- 1 Développeur Front-End
## Product Design (UX/UI)
Notre équipe a accompagné _Cuisinez pour Bébé_ dans la conception complète de l’expérience mobile, depuis la compréhension des usages jusqu’à la définition des parcours :
- Analyse des besoins des jeunes parents et identification des attentes spécifiques sur mobile
- Structuration de l’architecture de l’information et conception de parcours simples et centrés sur les usages réels
- Prototypes basse fidélité → prototypes haute fidélité (_maquettes interactives_)
- Plusieurs cycles d’itération réalisés avec le client pour affiner les parcours et valider les choix de conception
## Développement
Côté technique, BearStudio a assuré la réalisation de l’application mobile connectée à l’infrastructure WordPress existante :
- Développement mobile en React Native (_Android & iOS_)
- Intégration des contenus via API REST WordPress (_recettes, menus, profils_)
- Mise en place de la recherche Algolia pour un accès rapide et filtré aux recettes
- Gestion de l’authentification et du modèle freemium / abonnés
- Optimisation de la cohérence visuelle et technique grâce à des composants partagés et une communication étroite entre designers et développeurs
## Conception & itérations
### Écrans principaux de la V1 - Poser les fondations
La première version de l’application _Cuisinez pour Bébé_ avait pour objectif de transposer les fonctionnalités clés du site existant vers un environnement mobile.
Cette V1 constituait un socle fonctionnel, pensé pour répondre en priorité aux usages essentiels identifiés par l’équipe CPB : **consulter des recettes**, **organiser les repas de la semaine et comprendre la valeur de l’abonnement**.
À ce stade, l’enjeu n’était pas encore d’optimiser chaque interaction, mais de valider les parcours fondamentaux et la pertinence du format applicatif.
L’application s’articulait ainsi autour de quelques briques centrales :
1. **L’accès aux menus hebdomadaires** dès l’entrée dans l’app
2. La **consultation d’un catalogue de recettes** classées par âge
3. **Des fiches recettes** simples regroupant les informations nécessaires à la préparation
4. **Un espace favoris** pour retrouver les contenus enregistrés
5. Un **profil utilisateur** orienté **gestion du compte** et de **l’abonnement**
6. **Un paywall** destiné à présenter l’offre freemium
7. **Un parcours d’inscription** volontairement très séquencé
Cette première version a permis de poser les bases du produit, de confronter les hypothèses initiales aux usages réels et de fournir un terrain solide pour les évolutions futures.
### Les écrans principaux aujourd’hui
Les écrans actuels de _Cuisinez pour Bébé_ ne sont pas le résultat d’un empilement de fonctionnalités. Ils sont le résultat d’une démarche centrée sur des usages concrets, itérée dans le temps, avec un objectif constant : rendre une expérience riche simple à utiliser sur mobile, dans un contexte réel (_parent pressé, téléphone à une main, enfant à gérer, cuisine en cours_).
Plutôt que de concevoir écran par écran, nous avons structuré l’application autour de parcours “moteurs”, ceux qui reviennent le plus souvent dans le quotidien des parents :
- Planifier les repas de la semaine sans réfléchir à chaque décision
- Trouver rapidement une recette pertinente _(âge, texture, contexte)_
- Cuisiner sans friction, en gardant une lecture claire et continue
- Suivre la diversification alimentaire dans le temps
- Gérer un profil familial et l’accès au premium sans confusion
### Méthode de conception
Pour transformer ces usages en expérience mobile, nous avons privilégié une approche très concrète : **prototyper, simuler, observer, ajuster**.
Nous avons utilisé des prototypes interactifs pour valider :
- La compréhension des enchaînements _(où cliquer, quand et pourquoi)_
- La profondeur de navigation _(éviter les tunnels)_
- La lisibilité et la hiérarchie de l’information dans des listes denses
- La cohérence entre écrans _(mêmes repères visuels, mêmes codes)_
Cette méthode permettait de tester rapidement des hypothèses avant développement et de détecter tôt des problèmes typiques du mobile : surcharge visuelle, gestes peu accessibles, filtres trop complexes, actions secondaires trop visibles, manque de continuité entre listing et détail.
### Ce que cette démarche a changé
Au fil des itérations, plusieurs axes se sont imposés comme structurants :
- Hiérarchiser l’information plutôt que tout afficher : photo, titre, âge et quelques repères forts avant le reste
- Raccourcir le chemin vers l’action : ouvrir une recette, ajouter en favori, générer des courses, sans multiplier les écrans
- Créer des écrans “carrefours” _(ex. Menu hebdo, Recettes)_ qui concentrent le besoin principal, puis renvoient vers des détails au moment opportun
- Assurer une continuité visuelle : si un parent comprend une carte recette dans le catalogue, il doit la comprendre partout _(menu, favoris, suggestions)_
Les écrans “aujourd’hui” incarnent ce niveau d’équilibre atteint : une interface capable d’absorber des contenus denses et variables, tout en restant fluide, cohérente et rassurante.
###### _Aperçu des écrans actuels : organisation, exploration, exécution, suivi._

### Zoom design - Composant Carte Recettes
La section Recettes est l’un des modules les plus exigeants de l’application. C’est un espace où l’utilisateur doit pouvoir explorer rapidement un catalogue très large, tout en gardant un sentiment de maîtrise.
#### Intention produit
L’objectif central n’était pas de proposer un moteur de recherche avancé. L’objectif était de permettre une prise de décision simple, à partir de critères qui ont du sens pour les parents : **âge, texture, type de repas, contraintes alimentaires, contexte du moment**.
Autrement dit, la section recettes devait fonctionner comme :
- Une source d’inspiration
- Un outil de tri
- Un point d’accès rapide à l’action _(cuisiner, enregistrer, planifier)_
###### _Le catalogue est conçu pour être scanné en quelques secondes : image, titre, âge._

#### Contraintes rencontrées
Cette section cumule plusieurs contraintes complexes :
- **Densité** : beaucoup de recettes à l’écran et beaucoup de recettes au total
- **Variabilité** : titres très longs, informations différentes selon recettes
- **Multi-critères** : le bon choix dépend de plusieurs paramètres _(âge, texture, type, ingrédients)_
- **Mobile**: interactions courtes, gestes simples, lisibilité immédiate
- **Continuité** : la liste doit préparer la fiche recette, sans rupture
Le risque principal était double :
- Un catalogue trop “riche” visuellement, où on ne lit plus rien
- Ou un système de filtres trop complexe, qui décourage l’exploration
#### Décision clé n°1 : la carte de recette comme unité de lecture
La carte recette est le composant qui porte l’essentiel de la compréhension. Elle doit permettre trois actions mentales très rapides :
1. Reconnaître l’idée _(via l’image)_
2. Comprendre le contenu _(via le titre)_
3. Valider l’adéquation _(via l’âge)_
Cela implique une hiérarchie stricte :
- **Image dominante** : l’œil décide d’abord par le visuel, un parti pris rendu évident par la richesse et la qualité exceptionnelle des photos de _Cuisinez pour Bébé_, véritable atout visuel de la marque
- **Titre optimisé pour le long** : typographie, espace, nombre de lignes
- **Âge présent mais secondaire** : visible, sans voler l’attention

#### Décision clé n°2 : les filtres comme levier principal (et non un “plus”)
Dans cette application, les filtres ne sont pas une fonctionnalité secondaire. Ils sont le mécanisme qui rend le catalogue utilisable au quotidien.
L’idée n’était pas “mettre beaucoup de filtres” mais de **proposer un système qui aide à réduire progressivement l’espace de recherche sans exiger un effort mental important**.
Les choix qui rendent les filtres efficaces :
- **Catégorisation claire** : on raisonne par familles _(régime, type, moment, saison, particularités)_
- **Sélection rapide**
- **Validation explicite** : appliquer quand on est prêt, plutôt que déclencher des résultats à chaque micro-choix
- **Feedback immédiat** : voir le nombre de recettes trouvées évite l’impression “je filtre dans le vide”

## Une collaboration qui se construit dans la durée
Depuis 2021, la collaboration entre BearStudio et l’équipe _Cuisinez pour Bébé_ s’inscrit dans le temps. Elle repose sur une relation de confiance, une grande réactivité et un dialogue constant autour de l’évolution du produit.
L’équipe CPB partage régulièrement des retours issus de sa communauté, formule de nouvelles idées et sollicite des conseils pour faire évoluer l’application.
Ces échanges prennent différentes formes : messages Slack, points réguliers, ou encore des vidéos Loom pour détailler des attentes ou proposer des pistes d’amélioration ou demander des conseils.
Cette dynamique a permis de faire évoluer progressivement l’application au-delà de sa première version.
Plusieurs fonctionnalités majeures ont ainsi enrichi l’expérience au fil du temps, comme **la gestion de plusieurs enfants** au sein d’un même compte ou la mise en place de **la liste de courses**, devenues un élément clé de l’organisation quotidienne.
Certaines fonctionnalités existantes ont également été retravaillées et affinées, notamment autour de **l’accès au contenu premium** et des écrans de conversion, afin d’améliorer la clarté et l’expérience globale.
Ce rythme d’itération partagé permet au produit de rester vivant, aligné avec les besoins réels des parents, et d’évoluer en continu, porté conjointement par les équipes CPB et BearStudio.
## Ce que les utilisateurs en disent
Au-delà des maquettes, des fonctionnalités et des itérations, l’indicateur le plus précieux reste la satisfaction des utilisateurs.
Depuis le lancement de l’application, les retours laissés sur les stores et les messages envoyés à CPB témoignent d’un impact réel dans le quotidien des parents.
Ce qui ressort le plus souvent :
- La simplicité d’utilisation
- La clarté des recettes
- Le gain de temps dans l’organisation des repas
- La qualité du contenu proposé
- La confiance accordée à l’univers CPB
Les notes laissées sur l’App Store et Google Play, ainsi que les nombreux messages positifs, confirment que l’application répond à un besoin fort : **accompagner les parents de manière fiable, intuitive et bienveillante**.
Ces retours nourrissent à leur tour le projet, car chaque commentaire constructif ou demande récurrente inspire de futures évolutions renforçant encore davantage le cycle d’amélioration continue entre CPB, ses utilisateurs et notre équipe.

## Pour aller plus loin
_Cuisinez pour Bébé_ continue d’accompagner chaque jour des milliers de parents grâce à son écosystème de contenus, son application et ses ressources pédagogiques.
Pour découvrir l’univers complet, voici où trouver la marque et suivre ses dernières nouveautés :
**Site web officiel** : Recettes, conseils, batch cooking et guides pratiques
[https://www.cuisinez-pour-bebe.fr/](https://www.cuisinez-pour-bebe.fr/)
**Application mobile** : Disponible sur l’App Store et Google Play
Accès aux menus hebdomadaires, filtres, favoris, liste de courses et fonctionnalités premium
**Instagram** : Partage de recettes, astuces, vidéos pratiques, retours de la communauté
[https://www.instagram.com/cuisinezpourbebe/](https://www.instagram.com/cuisinezpourbebe/)
**Facebook** : Communauté active, échanges entre parents, lives et contenus exclusifs
[https://www.facebook.com/cuisinezpourbebe/](https://www.facebook.com/cuisinezpourbebe/)
**YouTube** : Vidéos explicatives, recettes filmées, ateliers et masterclass
[https://www.youtube.com/cuisinezpourbebe](https://www.youtube.com/cuisinezpourbebe)
Et n'hésitez pas à découvrir [notre précédente étude de cas sur Léa English](/fr/blog/articles/lea-english-etude-de-cas) !
---
### Ficus UI 🌿 — UI simple et composable pour React Native
URL: https://www.bearstudio.fr/fr/blog/articles/ficus-ui-ui-simple-et-composable-pour-react-native
Date: 2025-12-24
**La conception d’une librairie UI React Native cohérente et maintenable** est un enjeu central dans le développement d’applications mobiles modernes. Depuis de nombreuses années, nous utilisons React Native pour ses capacités cross-platform, qui permettent de cibler à la fois Android et iOS tout en conservant les avantages de React et du mobile natif.
Cependant, la gestion du style et de l’UI React Native reste limitée par défaut : le framework fournit des composants de base pour structurer les vues, mais peu d’outils pour créer des interfaces mobiles avancées, personnalisables et cohérentes à grande échelle.
La communauté React Native a rapidement développé des librairies UI pour corriger ces problèmes, mais nous n’avons pas trouvé une librairie qui corresponde à ce que nous utilisons sur React web : [Chakra UI](https://chakra-ui.com/)
C’est pourquoi nous avons développé au [BearStudio](/fr/) une nouvelle librairie UI open source : [React Native Ficus UI 🌿](https://ficus-ui.com/)
## Pourquoi Ficus UI ?
Nous aimons Chakra UI pour plusieurs raisons : sa simplicité, sa cohérence, et sa philosophie “styled system” qui permet de construire rapidement des interfaces élégantes, accessibles et personnalisables.
Lorsque nous avons commencé à chercher une expérience similaire sur React Native, nous avons découvert qu’aucune librairie ne combinait vraiment ces qualités.
Certaines librairies proposaient des composants riches mais difficiles à thématiser. D’autres offraient de la flexibilité, mais au prix d’une grande complexité ou d’un manque de cohérence entre composants.
**Ficus UI** est née de ce constat : proposer une **expérience Chakra-like pour React Native**, avec une API simple, expressive, et 100 % compatible avec les contraintes du mobile.
## Comparaison avec l'UI React Native “de base”
Avant Ficus UI, la plupart des interfaces React Native étaient construites avec les composants et styles natifs (`View`, `Text`, `StyleSheet.create`).
Cela fonctionne très bien… mais c’est souvent verbeux, peu expressif et difficile à maintenir à mesure que l’application grandit.
### En React Native “classique”

```tsx
import { StyleSheet, Text, TouchableOpacity, View } from 'react-native';
export default function Card() {
return (
React Native Ficus UI 🌿
Découvrez Ficus UI pour vos apps React Native
Explorer
);
}
const styles = StyleSheet.create({
card: {
backgroundColor: '#f7fafc',
padding: 16,
borderRadius: 12,
shadowColor: '#000',
shadowOpacity: 0.1,
shadowRadius: 4,
},
title: {
fontSize: 24,
fontWeight: 'bold',
color: '#2d3748',
marginBottom: 8,
},
subtitle: {
fontSize: 16,
color: '#4a5568',
marginBottom: 12,
},
button: {
backgroundColor: '#319795',
paddingVertical: 10,
borderRadius: 6,
},
buttonText: {
color: '#fff',
fontWeight: '600',
textAlign: 'center',
},
});
```
Ce code est fonctionnel, mais il :
- nécessite **un bloc de styles séparé**, souvent redondant,
- rend la lecture moins fluide,
- ne s’adapte pas facilement à un thème ou au mode sombre,
- et complexifie la réutilisation (chaque composant gère ses propres styles).
### Avec Ficus UI
Le même composant, écrit avec Ficus UI, devient beaucoup plus **déclaratif et composable** :
```tsx
import { Box, Button, Text } from 'react-native-ficus-ui';
export default function Card() {
return (
React Native Ficus UI 🌿
Découvrez Ficus UI pour vos apps React Native
);
}
```
**Différences majeures :**
- Plus **aucun StyleSheet** à maintenir : les styles sont intégrés sous forme de props.
- Les **couleurs, espacements et tailles** sont reliés au thème global.
- Le composant est **auto-documenté** : la structure et le style se lisent ensemble.
- Le thème gère **dark mode, responsive et color schemes** sans effort supplémentaire.
En d’autres termes :
> Avec React Native “vanilla”, vous décrivez comment styliser.
>
> Avec Ficus UI, vous décrivez _ce que vous voulez obtenir_.
## Un système de thème puissant et personnalisable
Ficus UI intègre un **système de thème centralisé**, inspiré de Chakra UI, qui définit les couleurs, espacements, typographies, breakpoints et variantes globales de vos composants.
Cela permet de maintenir une cohérence visuelle sur l’ensemble de votre application tout en facilitant la personnalisation de votre design system.

```tsx
import { AppRegistry } from 'react-native';
import { ThemeProvider } from 'react-native-ficus-ui';
import App from './src/App';
// this is our custom theme
const theme = {
colors: {
// Use Smart Swatch to generate colors palette
violet: {
50: '#f0eaff',
100: '#d1c1f4',
200: '#b199e7',
300: '#9171dc',
400: '#7248d0',
500: '#592fb7',
600: '#45248f',
700: '#311968',
800: '#1e0f40',
900: '#0c031b',
},
},
fontSizes: {
'6xl': 32,
},
space: {
xs: 2,
'5xl': 64,
},
// components defaults can also be customized
components: {
Text: {
color: 'gray.100',
},
},
};
export default function Main() {
return (
);
}
```
## Créez vos propres composants avec `ficus()`
L’un des aspects les plus puissants de Ficus UI est sa fonction `ficus()`, qui vous permet de **transformer n’importe quel composant React Native ou tiers en composant Ficus**.
Cela facilite l’intégration d’éléments personnalisés dans votre design system, tout en bénéficiant des style props.

```tsx
import { View } from 'react-native';
import { ficus } from 'react-native-ficus-ui';
const Circle = ficus(View, {
baseStyle: {
borderRadius: 'full',
bg: 'teal.500',
},
});
;
```
En quelques lignes, votre composant adopte toute la puissance de Ficus : thème, responsive, color schemes, etc.
## Concilier React Native et Chakra UI
Ficus UI ne cherche pas à remplacer React Native, mais à **lui ajouter une couche de confort et de cohérence** inspirée de Chakra UI.
Elle conserve donc les **composants natifs que tout développeur React Native connaît déjà**, tout en leur ajoutant la puissance du système de style et du thème.
### Les composants de base que vous connaissez
Plutôt que de réinventer des noms, Ficus UI conserve les mêmes composants que ceux du cœur de React Native :
- `Button` → un bouton stylisé, mais basé sur le `Pressable` natif
- `Pressable`, `TouchableOpacity`, `TouchableHighlight`, etc. → toujours disponibles et compatibles
- `Text`, `Image`, `Input` → inchangés, mais avec **style props** et **thème**
- `Box` et `ScrollBox` → les uniques exceptions volontaires, qui remplacent `View` et `ScrollView` pour correspondre à l’API de Chakra UI
Ainsi, **vous gardez vos réflexes de React Native**, tout en gagnant la syntaxe et la souplesse d’un système inspiré du web.
### Des surcouches utiles à des librairies populaires
En plus des composants de base enrichis, Ficus UI propose des **composants “haut niveau”** qui encapsulent des usages fréquents dans les apps mobiles modernes.
Ces composants s’appuient sur des librairies React Native reconnues, mais avec une API simplifiée, cohérente et thématique.
### `PinInput`

[Tester sur la doc](https://ficus-ui.com/docs/Components/Inputs/pininput)
```tsx
const SimplePinInput = () => {
const [pinValue, setPinValue] = React.useState(null);
return (
);
};
```
Basé sur [https://github.com/retyui/react-native-confirmation-code-field](https://github.com/retyui/react-native-confirmation-code-field)
### `Slider`

[Tester sur la doc](https://ficus-ui.com/docs/Components/Inputs/slider)
```tsx
```
Repose sur [https://github.com/callstack/react-native-slider](https://github.com/callstack/react-native-slider)
### `DraggableModal`

[Tester sur la doc](https://ficus-ui.com/docs/Components/draggable-modal)
```tsx
const SimpleModal = () => {
const { isOpen, onOpen, onClose } = useDisclosure();
return (
Settings
Your settings
);
};
```
Basée sur [`react-native-bottom-sheet`](https://github.com/gorhom/react-native-bottom-sheet)
### `Tabs`

[Tester sur la doc](https://ficus-ui.com/docs/Components/Layout/tabs)
```tsx
Tab 1Tab 2Content for the first tabContent for the second tab
```
- Inspiré de Chakra UI Tabs
- Basé sur `[react-native-tab-view](https://github.com/react-navigation/react-navigation)`
👉 En résumé :
Ficus UI **ne masque pas React Native,** elle **l’enrichit**.
Vous utilisez les composants que vous connaissez déjà, avec une **API plus fluide**, un **thème cohérent**, et des **intégrations prêtes à l’emploi** pour les cas d’usage modernes.
## Responsive et cross-platform par design
Le responsive est souvent un casse-tête sur React Native.
Avec Ficus UI, les style props peuvent accepter des **valeurs par breakpoint**, comme sur le web :
```tsx
Layout adaptatif
```
Cela permet de gérer facilement les différences entre téléphones, tablettes, et grands écrans, tout en conservant une syntaxe claire et déclarative.
## Dark mode natif et intelligent
Le **dark mode** est aujourd’hui attendu dans toutes les applications mobiles — il améliore le confort visuel, économise la batterie, et offre une expérience plus personnalisée à l’utilisateur.
Avec Ficus UI, le mode sombre est **intégré nativement** : inutile de gérer manuellement des styles conditionnels ou des thèmes séparés.
### Un thème adaptatif, basé sur les préférences système
Ficus UI détecte automatiquement la préférence de l’utilisateur (sombre ou clair) et adapte dynamiquement les couleurs du thème.
Vous pouvez aussi forcer un mode ou basculer manuellement entre les deux.
```tsx
const { colorMode, toggleColorMode } = useColorMode();
;
```
Les **color schemes** assurent un contraste optimal et une cohérence visuelle automatique.
## Comparaison avec les autres librairies UI React Native(2025)
| Librairie | Points forts | Ce que Ficus UI apporte en plus |
| ----------------------------- | ------------------------- | -------------------------------------------------------- |
| **NativeBase / Gluestack UI** | Complet, riche, maintenu | API plus proche de Chakra UI |
| **React Native Paper** | Basée sur Material Design | Ficus UI est agnostique, pas limitée par Material Design |
| **UI Kitten** | Complet | API moins intuitive |
| **Tamagui** | Cross-platform performant | API plus proche de Chakra UI |
| **Dripsy** | Minimal et extensible | Moins de composants prêts à l’emploi |
Ficus UI vise le juste équilibre : **puissant sans être complexe**, **léger sans être limité**, et **familier pour les équipes web + mobile**.
## 🌿 En conclusion
Ficus UI, c’est notre manière de **rendre le développement mobile plus fluide, cohérent et agréable**.
C’est une librairie qui reflète notre philosophie : **des outils simples, composables, et faits pour durer**.
👉 Découvrez-la sur [ficus-ui.com](https://ficus-ui.com/?utm_source=chatgpt.com)
👉 Contribuez sur [GitHub](https://github.com/BearStudio/react-native-ficus-ui?utm_source=chatgpt.com)
Et n'hésitez pas à découvrir nos autres projets open-source :
- [Start UI \[Web\]](/fr/blog/articles/start-ui)
- [UI-State](/fr/blog/articles/pourquoi-on-a-cree-ui-state)
---
### Octobre spooky au BearStudio : entre commits et décorations
URL: https://www.bearstudio.fr/fr/blog/articles/octobre-spooky-au-bearstudio-entre-commits-et-decorations
Date: 2025-11-18
L’automne s’installe, les jours raccourcissent et la nuit s’invite un peu plus tôt derrière nos écrans. 🌒 Le froid se glisse entre deux commits, et les premiers frissons se font sentir. Difficile de dire s’ils viennent du vent glacial ou d’un bug en production. 👀
Entre les lignes fantômes (celles qui déclenchent une erreur à la ligne 45 alors que cette ligne n’existe même pas), et les bugs farceurs qui nous jouent des tours… le décor était déjà planté.
Voici donc un bref retour sur le mois d’octobre au [BearStudio](/fr/). Où l’ambiance d’Halloween a pris le contrôle de la tanière de l’équipe. Mais comme on n’est pas du genre à se laisser hanter, on en a aussi profité pour entretenir la bonne humeur, la créativité et une petite touche d’écolo-décoration en matériaux de récup. 🎃
## 1. Atelier découpe de citrouilles
##### Semaine du 6 au 13 octobre
Première étape : la traditionnelle **découpe de citrouilles !**
Sous les derniers rayons de soleil d’octobre, on s’est installés dehors, armés de couteaux, de cuillères et d’un courage variable selon les participants.
Certaines citrouilles sont devenues de véritables œuvres d’art… d’autres, des exceptions non gérées. 😅


“Rien ne se perd, rien ne se crée, tout se transforme”: les restes ont été recyclés — pas en carrosse (on n’a pas trouvé le bon _framework_ pour ça) — mais en un délicieux **velouté de citrouille** pour nous réchauffer.
Et pour les plus gourmands : **petits gâteaux citrouille-cranberry**. Comme Rust, ça a divisé : certains ont adoré, d’autres ont préféré ne pas relancer le script. Pour les curieux, vous pouvez aller voir l’article de Yoann [ici](/fr/blog/articles/rust).

## 2. Atelier décoration
##### Semaine du 13 au 20 octobre
Deuxième phase : la **déco d’Halloween.**
Après une brève _inspiration Instagram_ (et quelques échecs critiques), on a finalement pris le coup de main.
Astuce du jour : coller avec de l’eau, c’est écolo… mais ça a son caractère et ça demande un peu de patience pour que ça tienne ! Un peu comme quand on teste un nouveau snippet de code : parfois ça prend au premier essai. Et parfois il faut ajuster quelques détails pour que tout s’imbrique parfaitement. 😬



### 3. Atelier guirlandes
##### Semaine du 20 au 27 octobre
Place au **recyclage créatif !**
Rouleaux de papier toilette, chutes de papier coloré, un marqueur et un bout de ficelle plus tard. Et voilà une armée de petits fantômes, citrouilles, chauves-souris, autres créatures étranges prêtes à envahir le bureau.
Certains personnages avaient l’air terrifiants, d’autres… un peu trop mignons pour faire peur.
Mais l’ambiance spooky était au rendez-vous entre deux cafés et trois commits sur _Lea English_ (dont vous pouvez lire l’étude de cas UX [ici](/fr/blog/articles/lea-english-etude-de-cas)) !



## 4. Soirée Loup-Garou
##### Le 30 octobre
Pas de pleine lune sans **Loup-Garou** !
Chacun sous son plaid avec un chocolat chaud ou son dîner. Connectés sur le site [Wolfy](https://wolfy.net/fr) pour une soirée pleine de trahisons numériques et de débats intenses sur “qui est le loup garou ?”, “qui sera le maire” ou encore “qui est cupidon ? on a des comptes à régler...”.🐺

Et un petit GarticPhone qui n’avait plus rien à voir avec Halloween pour finir en beauté (des dessins faits au pad et un talent incertain qui nous a encore plus fait rire ! ).


Bref, un mois d’octobre bien rempli au BearStudio : des citrouilles, du code, des rires et quelques frayeurs… mais surtout, une équipe d’ours qui sait transformer les _bugs_ en bonbons 🍬 et les _pull requests_ sur [Start UI](/fr/blog/articles/start-ui) en moments de partage.

---
### Les coulisses d’un teambuilding à Disneyland Paris
URL: https://www.bearstudio.fr/fr/blog/articles/les-coulisses-dun-teambuilding-a-disneyland-paris
Date: 2025-10-30
Le dernier week end d’août 2025, le [BearStudio](/fr/) a offert à tous ses salariés et leurs proches, un week end teambuilding à [Disneyland Paris](https://www.disneylandparis.com/fr-fr).
Organiser un team building à Disney, c’est comme préparer un spectacle. Il faut un scénario, des acteurs motivés, et une logistique sans faille. Retour sur les coulisses de ce projet, de l’idée initiale à la concrétisation, en passant par les choix stratégiques et les ajustements nécessaires.
## Étape 1 : Choisir le type d’événement
L’idée de départ pour les dirigeants est d’offrir une sortie assez simple à organiser et classique en attendant le big 2026. Il nous faut un moment de partage fun pour renforcer la cohésion d’équipe. Un parc d'attractions semble tout de suite le lieu idéal. La moyenne d’âge au BearStudio se situe autour de 30 ans et certains collaborateurs ont désormais des enfants en bas âge.
Nous avons évoqué plusieurs parcs d'attractions et réfléchi en fonction de la distance et des activités proposées, au parc le mieux adapté pour le BearStudio.
Ensuite je me suis renseignée sur les tarifs (parc, hôtel et trajet) pour avoir une idée du budget et définir une limite. On a beau vouloir faire plaisir à tout le monde, il faut définir une limite afin que le budget n'explose pas. Il arrive au CEO de s’enflammer donc on est là, la DAF et moi pour faire en sorte de rester raisonnables.
En mars, nous avons créé sur notre Slack interne un channel dédié à l'organisation de ce teambuilding.
## Étape 2 : Sondage pour la date et le Parc
Afin d’impliquer l’équipe, un premier sondage a été envoyé mi-mars pour connaître les préférences de chacun : le choix était donné entre 2 jours à Disneyland Paris et 2 jours au Futuroscope. Nous leur avons également demandé de choisir entre deux week-ends de juin ou août. Ce week end n’est pas obligatoire mais nous espérions avoir le maximum de collaborateurs.
Finalement, les réponses au sondage pour choisir le parc ne nous aident pas beaucoup car on arrive à un beau 50/50.
Pour les dates on se dirige vers fin août. Ce sondage nous permet aussi d'évaluer le nombre de participants et d’avoir une base pour affiner le budget.
## Étape 3 : le choix
Au vu des retours de l’équipe et des coûts de chaque parc, les dirigeants ont tranché fin mars : ce sera sur Disney, le dernier week-end d'août.
## Étape 4 : Réservations et logistique
On avance, on avance et mi-avril nous avons organisé un nouveau sondage pour avoir une idée plus précise du nombre de participants. Tous les membres sont invités avec leurs enfants (les stagiaires aussi of course) et ils peuvent inviter un proche.
Mi-mai nous avons finalement porté notre choix sur un séjour de 2 jours et une nuit, avec accès aux 2 parcs de Disney. Nous sommes une trentaine et le budget doit rester raisonnable car le team-building 2026 pour fêter les 10 ans de l'entreprise reste la priorité en termes de coût.
Afin de communiquer sur l'événement avec la team. J’ouvre en juin un nouveau channel sur slack spécial Disney août 2025, réservé aux participants.
Début juin nous avons pu réserver le séjour et le restaurant. Le système de réservation de Disney n’est pas user friendly et on peut juste dire que l’informatique semble être la dernière roue du carrosse de Cendrillon. Leur système de réservation n’est pas très intuitif et assez complexe. Bref c’est laborieux, rien que pour remplir un tableau.
Heureusement, les employés que j’ai au téléphone sont aimables et disponibles. Nous avons choisi un hôtel Disney pour que l’expérience soit complète et les parcs accessibles en 10 min à pied. Le nombre de chambres est désormais fixé. Nous ne pouvons plus modifier sans frais. Le restaurant lui se trouve dans le village Disney. Nous avons choisi un buffet afin que tout le monde y trouve son compte quelque soit ses préférences alimentaires.
Tous les participants au week-end ont accepté avec plaisir ce repas convivial tous ensemble le samedi soir. Il m’a fallu également décider de l’horaire pour ce restaurant en tenant compte des heures des différents spectacles de soirée proposés par Disney. J’avais regardé au début de processus d'autres restaurants en dehors du parc. Mais il est compliqué de trouver des restaurants acceptant 30 convives et proposant des menus inclusifs. De plus, le peu que j'avais trouvé n'était pas moins cher et plus loin.
Reste à verser l’acompte. Le nombre de participants est figé. Le 9 juin, nous sommes à mi-parcours. Le solde sera à verser avant fin juillet. Il faut veiller à ne pas oublier de faire ce versement pendant les vacances.
Fin juillet c’est aussi la date limite pour confirmer la répartition des chambres.
J’organise les chambres en optimisant le nombre de participants par chambre tout en pensant à constituer des groupes agréables pour toutes et tous, dans des chambres de 4 personnes maximum.. Les familles avec enfants seront dans des chambres à part. Nous avons soumis cette répartition aux participants en espérant avoir répondu aux attentes de chacune et chacun pour avoir le moins de modifications possibles à effectuer. En fin de compte, tout le monde semble satisfait car aucun changement n’est demandé. Nous pouvons confirmer la répartition des chambres ainsi que le nom des participants. Nous serons 28 adultes, 2 enfants et 2 bébés.
## Étape 5 : Communication et suivi
Fin juillet j’ai commencé à parler de l’organisation du covoiturage pour le samedi matin et à donner les informations sur l'hôtel et le restaurant réservés.
Début août, j’ai diffusé sur le channel dédié un tableau à remplir pour organiser les voitures et j’ai compté sur l'équipe qu’ils s’organisent entre eux. Je leur ai donné les infos nécessaires, comme le temps de déplacement et l’heure d’arrivée à l'hôtel à respecter. J’ai ajouté les infos sur le parking et les bagages ainsi que la lettre d’invitation donnée par Disney.
Le groupe a bien répondu et mi août les voitures étaient organisées.
Le 26 août, 4 jours avant le départ. J’ai de nouveau fait un rappel pour les heures de départ des voitures ainsi que la procédure à suivre pour les clés des chambres. Disney ne propose pas de billet dématérialisé et les billets sont remis à une personne par chambre. Ce qui complique un peu l’organisation lorsque tous les membres d’une même chambre n’arrivent pas ensemble.
**Outils utilisés** :
- Tableau partagés sur Excel et Google Sheet pour centraliser les informations (participants, chambres, options).
- Sondages Slack pour les choix du restaurant et des activités.
- Canaux de communication : Le Slack interne de l’entreprise, un espace dédié pour partager les horaires, les chambres, et les mises à jour.
Nous avons également communiqué à l’oral lors des stand-up quotidiens en visio.
De nombreux rappel ont été nécessaires à l’oral et via Slack afin d’être sûrs que les informations soient bien passées et reçues par les participants. Et permettre d’avancer assez rapidement entre chaque étapes.
## Etape 6 : le jour J
Nous avons demandé à l’équipe d'être tous ensemble au point de rendez-vous à l'ouverture des Parcs. Pour profiter au maximum de toutes les activités proposées par Disney et de faire une belle photo de groupe pour se souvenir de ce teambuilding à Disneyland Paris. Nous avons finalement réussi à réunir tout le monde avec un retard d’environ 30 minutes seulement ! Ce qui, je trouve, était une belle réussite.
En dehors de ce rendez-vous matinal et du restaurant du samedi soir. Nous n’avons pas souhaité imposer d’activités spécifiques en groupe. Pour que chacun profite des parcs à son rythme en fonction de ses envies et possibilités.
Néanmoins, je note que naturellement des groupes de 4 à 10 personnes se sont constitués. Certains migrants d’un groupe à l’autre au cours de la journée naturellement.
- **Conseils pour les futurs organisateurs :**
- Impliquer les participants dès le début pour garantir leur adhésion.
- Utiliser des outils collaboratifs (sondages, tableaux partagés) pour faciliter l’organisation.
- Anticiper les imprévus (budget, disponibilités, préférences).
- Prévoir un budget avec une marge de sécurité.
- Faire un rétroplanning pour toujours avoir du recul sur l’avancement de l’organisation et bien avoir en tête les dates clés.
- Communiquer régulièrement avec l’équipe pour ajuster les détails.
- Savoir demander l’avis des participants sans se perdre en voulant faire plaisir à tout le monde. Parfois il a fallu trancher car il est impossible de faire l'unanimité.
- Responsabiliser les salariés sur le fait que l’on ne peut pas tout organiser pour eux. Il faut qu’ils comprennent que la réussite du team building repose aussi sur leur implication.

## Conclusion : Une aventure collective
Organiser un teambuilding à Disneyland Paris, c’est bien plus que réserver des billets et des chambres. C’est un projet collaboratif, où chaque étape compte pour créer une expérience inoubliable. Grâce à une planification rigoureuse et une communication transparente, cette aventure a permis de fédérer l’équipe autour d’un moment de partage et de magie. Les photos et anecdotes partagées créent des souvenirs en commun qui participent à la cohésion du groupe.
##### Et pour continuer sur la lancée, jetez un oeil à nos autres articles :
- Du code au coeur : nos engagements associatifs annuels
- Les ours au camping des speakers 2023
---
### Pourquoi on a créé ui-state
URL: https://www.bearstudio.fr/fr/blog/articles/pourquoi-on-a-cree-ui-state
Date: 2025-10-16
Pourquoi a t'on créé [ui-state](https://github.com/BearStudio/ui-state), une librairie TypeScript de gestion d'états ? Tout viens de la lecture d'un très bon article de [Dominic Dorfmeister aka TkDodo](https://x.com/TkDodo) (on vous conseille aussi de [lire ses autres articles sur son blog](https://tkdodo.eu/blog/))
Dans [l’article Component Composition is great btw](https://tkdodo.eu/blog/component-composition-is-great-btw), TkDodo met en lumière un problème récurrent : gérer les états d’une UI (`loading`, `error`, `empty`, `success`, etc.) de façon lisible, maintenable et typée… sans exploser la structure de son composant.
Prenons le point de départ typique.
On écrit un composant simple :
```tsx
export function ShoppingList() {
const { data, isPending } = useQuery(/* ... */);
return (
Welcome 👋
{data?.assignee ? : null}
{isPending ? : null}
{data
? data.content.map((item) => )
: null}
);
}
```
Et là, en surface, tout semble "fonctionner".
Mais très vite, ça devient flou :
- Est-ce qu’on peut avoir `data` **et** `isPending` en même temps ?
- Est-ce que l’absence de `data` signifie une erreur ou une liste vide ?
- Que se passe-t-il si `data` est présent mais vide ?
On se retrouve à jongler entre plusieurs flags (`isPending`, `data`, `isError`, etc.) qui peuvent potentiellement faire que deux morceaux de l'UI s'affichent en même temps alors que ce n'était pas ce qu'on avait prévu.
**C’est difficile à lire, à tester et à maintenir.**
### La solution proposée par TkDodo
TkDodo propose alors un refacto plus explicite, basé sur des `early return` :
```tsx
function Layout(props: { children: ReactNode; title?: string }) {
return (
Welcome 👋 {props.title}{props.children}
);
}
export function ShoppingList() {
const { data, isPending } = useQuery(/* ... */);
if (isPending) {
return (
);
}
if (!data) {
return (
);
}
return (
{data.assignee ? : null}
{data.content.map((item) => (
))}
);
}
```
C’est **beaucoup plus clair.** À chaque état correspond un rendu.
Mais ça vient avec une contrepartie : **on doit extraire le layout dans un composant, et que faire si on ne veut pas que tout l'écran change ?** Le composant `Layout` est dupliqué dans chaque branche. On doit extraire le typage pour pouvoir typer les props du `Layout`. Et si on veut qu’une partie de l’interface reste constante entre les états (par exemple un header ou une sidebar) ou si une ou plusieurs parties du `Layout` sont dépendantes de l’état, on doit commencer à restructurer son code.
## Ce qu’on voulait : un seul état actif, bien typé, et exploitable où on veut
Chez [BearStudio](/fr/), on voulait garder le même principe fondamental :
- un seul état actif à la fois,
- exhaustivité garantie au typage,
- lisibilité de la logique d’affichage,
…mais **sans éclater le JSX**, ni structurer tout le rendu autour des cas.
On voulait pouvoir dire :
"Donne-nous l’état courant, on s’en occupe. Juste assure toi qu’on gère bien tous les états"
## C’est pour ça qu’on a créé ui-state
Avec `ui-state`, on transforme la réponse d’un `useQuery` (ou n’importe quelle source de données) en **état unique et explicite**, basé sur un seul appel à getUiState.
Voici comment on refactorerait le composant `ShoppingList` en utilisant `ui-state` :
```tsx
import { getUiState } from '@bearstudio/ui-state';
export function ShoppingList() {
const query = useQuery(/* ... */);
const ui = getUiState((set) => {
if (query.status === 'pending') return set('pending');
if (!query.data || query.data.content.length === 0) return set('empty');
return set('default', { data: query.data });
});
return (
Welcome 👋
{ui
.match(['pending', 'empty'], () => '')
.match('default', ({ data }) => data.title)
.exhaustive()}
{ui
.match('pending', () => )
.match('empty', () => )
.match('default', ({ data }) => (
<>
{!!data.assignee && }
{data.content.map((item) => (
))}
>
))
.exhaustive()}
);
}
```
Ce qu’on y gagne :
- Un **état unique** bien défini, toujours à jour.
- Une **exhaustivité au typage** via `.exhaustive()` qui garantit qu’aucun cas n’est oublié.
- **On garde le type narrowing** automatique de TypeScript en passant des arguments. Comme ici le `data` qui n’est plus typé comme optionnel car on a testé qu’il existait bien.
- Une **liberté de rendu complète**, sans devoir structurer l’arbre JSX autour des états.
- Une meilleure **testabilité** de la logique d’affichage : on peut tester la UI pour chaque cas d’état indépendamment.
Même principe que dans l’article de TkDodo mais **pas besoin de découper en 4 composants ou de structurer l’arbre JSX autour des états.**
On garde la logique claire et la **composition intacte.**
Lien du github : [https://github.com/BearStudio/ui-state](https://github.com/BearStudio/ui-state)
Et pour continuer sur la lancée, jetez un oeil à nos autres articles :
- [Start UI [Web]](/fr/blog/articles/start-ui)
- [Love letter aux side-projects](/fr/blog/articles/love-letter-aux-side-projects)
---
### Love letter aux side-projects
URL: https://www.bearstudio.fr/fr/blog/articles/love-letter-aux-side-projects
Date: 2025-09-30
_Faire un side project est le meilleur moyen d'apprendre et s'amuser en même temps. Laisse moi t'expliquer pourquoi !_
Si:
- Toi aussi tu as au moins une vingtaine de repos sur GitHub. Ils contiennent (et c'est déjà exceptionnel) juste un README.md qui dit que c'est en cours de dev. Pourtant, ça fait plus d'un an que tu n'as pas mis le nez dedans.
- Toi aussi tu es hyper hypé par un sujet pendant 1 semaine. Puis une nouveauté arrive et ce sujet tombe dans l'oubli aussi vite qu'il est arrivé.
- Toi aussi, parmi ces sides projects aucun n'est parti en prod (et je parle pas d'une prod avec que ta famille ou tes collègues dedans, ça compte pas ^^).
- T'as acheté un nom de domaine pour 1 an mais t'as encore rien mis dessus.
**Alors t'es un goat ! Sinon, regarde pourquoi tu devrais te lancer dans un side project 😄.**
## Pourquoi tu devrais faire des sides projects ?
Je fais parti de ceux qui pensent que c'est impossible de devenir bon dans un domaine sans avoir passé pas mal de temps à pratiquer.
C'est pas en binge watchant des tutos sur youtube, en lisant une tonne d'articles sur un sujet que tu vas devenir un expert dans celui-ci. Au mieux tu comprendras des concepts, tu pourras te faire un avis (et encore, ton avis sera biaisé par les sources que tu auras consulté). Mais quand faudra mettre les mains dans le cambouis tu te rendras compte que tu ne sais rien !
Faire ça, c'est le meilleur moyen pour devenir cette personne qui te fait la morale sur "les bonnes pratiques" ou qui dit qu'une techno c'est de la merde par rapport à une autre parce-qu'il a vu 3 vidéos dessus et lu 6 posts sur X.
Ne fait pas ça — c'est le meilleur moyen pour passer pour un con auprès de tes collègues et de perdre en crédibilité.
Rappelle-toi qu’un side project pour apprendre et s’amuser te permet de te confronter à de vrais problèmes et d’acquérir de l’expérience rapidement.
Après on ne va pas se mentir. Ne pas être motivé, ne pas trouver de sujet, ne pas avoir envie, ça nous arrive à tous. Plusieurs fois je me dis "ah tiens, je testerais bien de faire un truc comme ça". Puis je regarde 15 000 tutos sur le sujet et je repousse toujours le moment où il faut vraiment init un projet pour réellement tester, alors que c’est le meilleur moyen de se faire un vrai avis.
Du coup, fort de mon expérience de projets entamés (dans le meilleur des cas) et jamais terminés (tout le temps), je vais vous donner mes tips pour pouvoir mettre les mains dans le cambouis rapidement 😄.
### 1. C'est ok de regarder des tutos
> Wtf il viens de dire l'inverse 2 lignes au dessus...
Je vais compléter: c'est ok de regarder des tutos si **tu mets en pratique rapidement ce que tu viens de voir**, quitte à le faire en parallèle. Il faut savoir se dire allez go, je prend une idée de projet et je me lance avec ce que je viens de voir.
Le fait de commencer rapidement ton projet va te permettre de rencontrer des vraies problématiques qu'il te faudra corriger ou contourner. Ça te permet de focus sur des vrais problèmes de la vraie vie (et d'éviter de regarder un tuto sur comment mettre en place un load balancer alors qu'à la base tu voulais des pistes pour faire de l'authentification). Focus !
### 2. Pas d'idées ? Tkt
Une excuse pour ne pas commencer à coder rapidement c'est de ne pas avoir de sujet, ou de ne pas avoir d'idée originale/révolutionnaire.
#### Mettons les choses au clair tout de suite:
- 90% du temps, quand tu auras une idée quelqu'un aura déjà fait la même chose
- Cette même idée est souvent déjà mieux développée que ce que toi tu avais en tête initialement, et a potentiellement déjà des milliers d'utilisateurs.
#### Ça ne doit pas te décourager.
Continue avec ton idée, on s'en fout que quelqu'un l'ai déjà fait en mieux, que ce soit déjà un produit. C'est justement parce que ce projet te motive que ça te permettra d'aller loin et d'apprendre.
Si vraiment c'est un problème, quelques idées (classiques) si tu manques d'inspiration:
- [Build your own X](https://github.com/codecrafters-io/build-your-own-x) (il y a des sujets un peu énervés, mais c'est super intéressant et ça sort des projets un peu bateau).
- Une todolist (et ouais, j'm'en fous moi, je trouve que c'est un bon projet qui peut être rapidement fonctionnel et sur lequel tu peux ajouter pleins de choses si t'es motivé).
- Un racourcisseur d'url.
- ...
Si ça ne te convient pas, trouve un sujet que tu aimes, une passion que tu as, un point de frustration que tu rencontres tous les jours et vois comment tu peux développer un truc qui t'aiderai; c'est d'autant plus motivant si c'est un sujet qui te tient à coeur.
### 3. Fais du code crado, fais des erreurs, utilise des templates
Le but c'est de s'éclater ! donc si tu veux pas passer 15 ans à faire un code ultra clean, mais que ton projet n'est toujours pas sorti ça vaut pas le coup.
C'est ok d'avoir un truc pas super propre mais qui fonctionne; tu seras déjà allé plus loin que 80% des devs qui init un side project (je suis inclu dans ce pourcentage 👅).
Perso ce qui me décourage la plupart du temps, c'est toute la phase de setup nécessaire avant de se plonger dans ce qui est vraiment intéressant; pour éviter ça je te recommande vivement de partir d'un template (même minimaliste) qui t'évitera de te re-taper le même setup de projet en projet.
Ptit tip: faire ton template peut aussi être une idée de side-project 😉.
**Instant promo:** au Beartudio on a un starter production ready que j'utilise pour setup quelques-uns de mes side projects: [StartUI [web]](/fr/blog/articles/start-ui). Je te recommande vivement d'y jeter un coup d'oeil si tu aimes la stack react/typescript !

## Pour conclure
Soyons bien d'accord, tout ce qui est dit au dessus est mon avis. Pour moi, le principal but d'un side project, c'est pour apprendre et s’amuser. C'est le meilleur moyen d'apprendre sans même s'en rendre compte 🙌.
Bref, ayez du fun dans ce que vous faites !
---
### Découvrir le MCP : Une nouvelle approche pour vos agents IA
URL: https://www.bearstudio.fr/fr/blog/articles/decouvrir-le-mcp-une-nouvelle-approche-pour-vos-agents-ia
Date: 2025-08-14
[Cet article est également disponible en anglais ! 🇬🇧](https://noe.tatoud.com/blog/what-is-mcp/)
## État des lieux rapide
Ces derniers mois, l'efficacité des *LLM* n’a cessé de croître, bouleversant nos habitudes et notre quotidien de développeur. De plus en plus sollicités pour écrire du code, débogguer, concevoir ou nous assister à chaque étape de notre travail, ces modèles sont en train de devenir des copilotes incontournables.
> **LLM** (Large Language Model, ou grand modèle de langage) est une intelligence artificielle entraînée sur de grandes quantités de texte pour **comprendre, générer et raisonner en langage naturel**.
Le grand public a déjà commencé à adopter des outils comme ChatGPT (OpenAI), LeChat (Mistral), ou d’autres solutions basées sur l'IA générative.
Mais au-delà d'échanges textuels et d'interactions basiques, et si l’on allait plus loin ? Et si l’IA pouvait **interagir directement et en autonomie avec nos outils** ? Modifier du code ? Interroger une base de données ?
C’est précisément ce que permettent les **agents IA**.
## Quelle est la différence entre un bot, un assistant IA et un agent IA ?
##### Bot
C'est un programme très simple. Il suit des règles pré-définies et donne des réponses automatiques. Par exemple, un chatbot sur un site web qui vous propose des réponses toutes faites ("Tapez 1 pour parler à un conseiller").
👉 **Il ne comprend pas vraiment, il applique des scripts.**
##### Assistant IA (comme Siri, Alexa ou ChatGPT)
Il est plus avancé. Il comprend ce qu’on lui dit, répond de manière plus naturelle, et peut effectuer des tâches simples (envoyer un message, faire une recherche, etc.).
👉 **Il attend qu'on lui parle et fait ce qu’on lui demande, mais ne prend pas d’initiatives.**
##### Agent IA
C’est le niveau supérieur. Il peut **agir seul**, prendre des décisions **sans qu’on lui dise quoi faire**, et s’adapter à ce qui se passe autour de lui. Par exemple, un agent IA pourrait surveiller votre boîte mail, repérer un rendez-vous important, réserver un taxi et vous prévenir — sans que vous ayez à le demander.
**👉 Il est autonome, intelligent, et apprend avec le temps.**
Je ne vais pas rentrer dans les détails du fonctionnement d'un Agent IA mais vous pouvez lire cet article de Google qui est une bonne entrée en matière: [Google Cloud - Qu'est-ce q'un agent IA ?](https://cloud.google.com/discover/what-are-ai-agents?hl=fr)
Jusqu’à présent, une des contraintes principale dans la création d'un agent était qu'il fallait mettre en place des connecteurs uniques, très spécifiques à chaque source de données et à chaque modèle. Une approche fastidieuse, peu scalable, et rarement généralisable.
## MCP: Here comes a new challenger
C’est là que le **Model Context Protocol (MCP)** entre en scène. Lancé fin 2024 par **Anthropic** (l’entreprise à l’origine de Claude), ce protocole open-source offre aux agents IA une méthode simple, standardisée et sécurisée pour se connecter à des outils, données et services, **sans avoir besoin d'intégrations spécifiques à chaque fois**.
## Théorie : comment ça fonctionne ?
Derrière le Model Context Protocol se cache une idée simple mais puissante : permettre à une IA de **découvrir dynamiquement, interroger et manipuler des outils ou des services** sans avoir à écrire une intégration dédiée pour chaque cas. Pour y parvenir, MCP définit un protocole de communication standardisé entre différents acteurs.

##### Les acteurs :
**Hôtes MCP :** ce sont des applications comme Claude Desktop, des environnements de développement (IDEs) ou des outils d’IA qui souhaitent accéder à diverses sources de données ou capacités via MCP.
👉 **Ils envoient des requêtes pour enrichir leur contexte (code, fichiers, docs, etc.) en utilisant le protocole.**
**Clients MCP :** ce sont des composants intermédiaires qui gèrent une connexion 1:1 avec un serveur MCP.
👉 **Ils traduisent les requêtes des hôtes en appels vers un serveur MCP spécifique, assurant le dialogue entre les deux.**
**Serveurs MCP :** ce sont de petits programmes autonomes qui exposent une fonctionnalité ou un type de données via le protocole MCP (ex : fichiers locaux, historique Git, base de connaissances…).
👉 **Chaque serveur est spécialisé et peut être combiné avec d'autres** **pour enrichir les capacités d’un hôte.**
##### Et les assistants IA dans nos IDE ?
Les assistants IA que nous utilisons aujourd’hui dans nos environnements de développement ont déjà bien évolué. D’abord conçus pour suggérer du code ou répondre à des questions simples, ils deviennent peu à peu de **véritables agents intelligents**, capables de **comprendre le contexte**, **prendre des décisions**, et **agir directement dans nos projets**.
Avec l’arrivée du **mode agent** ces assistants gagnent en autonomie et en flexibilité. Ils peuvent désormais se connecter dynamiquement à des outils externes — bases de données, API, fichiers locaux, historique Git, etc... Cela leur permet non seulement de mieux répondre à nos requêtes, mais aussi d’exécuter des actions complexes de manière proactive, en s’adaptant à chaque contexte.
C’est une étape majeure : l’assistant devient acteur, intégré profondément dans notre environnement de travail.
Ajouter des serveurs MCP à ces agents permet de **déverrouiller des capacités sur mesure** : accéder à des données locales, interroger des services métier, ou manipuler des fichiers spécifiques. Cela transforme l’agent en **interface unifiée entre l’IA et nos outils**, sans avoir à coder chaque intégration à la main.
## Pratique : exemple concret avec TypeScript et `@modelcontextprotocol/sdk`
### Mise en situation
Extrait de données sur les employés :
```json
[
{
"nom": "Alice Dupont",
"poste": "Développeuse Frontend",
"anciennete": "3 ans",
"competences": "React, TypeScript, UI/UX",
"statut": "CDI"
},
{
"nom": "Mehdi Benali",
"poste": "Tech Lead Fullstack",
"anciennete": "5 ans",
"competences": "Java, React, Architecture",
"statut": "CDI"
},
{
"nom": "Julie Morel",
"poste": "QA Analyst",
"anciennete": "2 ans",
"competences": "Tests automatisés, Cypress",
"statut": "CDD"
},
{
"nom": "Thomas Leroy",
"poste": "Product Manager",
"anciennete": "4 ans",
"competences": "Agile, Roadmap, Communication",
"statut": "CDI"
},
{
"nom": "Claire Nguyen",
"poste": "Développeuse Backend",
"anciennete": "1 an",
"competences": "Node.js, PostgreSQL, Docker",
"statut": "Alternance"
},
{
"nom": "Romain Garcia",
"poste": "Designer UI/UX",
"anciennete": "2 ans",
"competences": "Figma, Accessibilité, Design Sys",
"statut": "Freelance"
}
]
```
L'objectif ici va être de construire un mini serveur MCP afin de récupérer cette liste et de l'utiliser via Cursor.
Initialiser un projet Node 24 avec pnpm :
```bash
$ mkdir demo-mcp
$ cd demo-mcp
$ pnpm init -y
```
Installer les dépendances :
```bash
$ pnpm add zod @modelcontextprotocol/sdk
```
Nous n'aurons besoin que d'un seul fichier : `main.ts`.
Commençons par créer notre serveur :
```typescript
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const server = new McpServer({
name: "Gestionnaire d'employés",
version: '1.0.0',
description: 'Un serveur MCP de démonstration',
});
```
Ok, maintenant ajoutons un outil (tool) à notre serveur.
On doit préciser trois choses importantes :
- Le nom de l’outil : `'getEmployees'`
- Une description : `"Récupère la liste de tous les employés en appliquant un filtre si nécessaire"`. Cela permet au LLM d’avoir plus de contexte pour savoir quand et comment l’utiliser.
- Un schéma de validation d’entrée, pour indiquer au LLM quels paramètres peuvent être utilisés. On peut utiliser n'importe quelle bibliothèque de validation suivant le [Standard Schema](https://github.com/standard-schema/standard-schema). Avec `zod`, on peut en plus ajouter des descriptions aux paramètres.
- Et bien sûr, le corps de la fonction exécutée par l’outil.
Ajoutons tout cela à notre fichier `main.ts` :
```typescript
server.tool(
'getEmployees',
'Récupère la liste de tous les employés en appliquant un filtre si nécessaire',
{
filter: z
.object({
key: z
.enum(['nom', 'poste', 'anciennete', 'competences', 'statut'])
.describe(
'Les clés de la table des employés utilisées pour filtrer les employés'
),
value: z.string(),
})
.optional()
.describe("Filtrer la liste d'employés"),
},
async ({ filter }) => {
const employees = await getEmployees({
where: filter?.key,
value: filter?.value,
});
return {
content: [{ type: 'text', text: JSON.stringify(employees, null, 2) }],
};
}
);
```
Super ! Notre serveur est presque prêt, mais il faut maintenant faire en sorte que les clients MCP puissent communiquer avec notre serveur.
Une solution simple est de lire depuis l’entrée standard et d’écrire sur la sortie standard du processus courant ( `stdio/stdout` ).
Heureusement, la bibliothèque `@modelcontextprotocol/sdk` fournit une abstraction simple pour cela : `StdioServerTransport` .
```typescript
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const transport = new StdioServerTransport();
await server.connect(transport);
```
Et voilà, notre serveur est désormais prêt à être utilisé !
Connectons-le à Cursor. Pour cela, il suffit d'ajouter dans notre fichier `.cursor/mcp.json` (à la racine de votre projet par exemple) :
```json
{
"mcpServers": {
"demo-mcp": {
"command": "npx",
"args": ["node", "/chemin-vers-votre-projet/demo-mcp/main.ts"]
}
}
}
```
Maintenant, notre agent IA a accès au serveur MCP et aux outils qu’il propose.
On peut vérifier que le serveur est bien connecté dans les paramètres de Cursor :

Maintenant, essayons de lui poser une question, par exemple :
**"Donne-moi la liste des employés qui sont en CDI."**
(Ici le modèle utilisé est `claude-3.5-sonnet`, mais cela n'a pas vraiment d’importance.)
Le LLM va comprendre qu’il peut faire appel à l’outil de notre serveur, choisir les bons paramètres, récupérer les données, et nous renvoyer une réponse formatée à partir de celles-ci

## À quoi s'attendre dans le futur ?
Depuis début 2025, l’adoption du **MCP** connaît une croissance fulgurante. De plus en plus d’acteurs, des startups aux grandes plateformes, contribuent à l’écosystème en publiant des **serveurs MCP** capables d’interagir avec toutes sortes de systèmes : bases de code, bases de données, APIs métier, outils internes, fichiers, etc.
Des noms comme **Microsoft**, **Cloudflare**, **Open AI** ou encore des éditeurs de frameworks et d’IDE s’impliquent activement.
MCP s’impose peu à peu comme le **standard d’interopérabilité entre IA et outils métiers**. Là où l’on bricolait des connecteurs spécifiques et rigides, on dispose désormais d’un protocole **modulaire, déclaratif et sécurisé**, conçu pour collaborer naturellement avec des modèles de langage.
Cela ouvre un nouveau champ de possibilités : agents personnalisés, automatisations intelligentes, assistants capables de naviguer dans une base de code ou d'analyser des logs en contexte, voire même des actions de haut niveau comme la gestion de déploiement ou le contrôle d’environnements.
Le tout, sans dépendance technologique forte : MCP est **ouvert, extensible et agnostique**, ce qui permet à n’importe quel outil ou service d’exposer ses capacités à la volée.
Alors si vous êtes curieux, testez-le, créez vos propres serveurs, exposez vos outils, et partagez vos expériences avec la communauté.
## Pour aller plus loin
👉 [Introduction - Model Context Protocol (Anthropic)](https://modelcontextprotocol.io/introduction)
👉 [Créez un serveur MCP en 5 étapes // Un codage efficace (Matt Pocock)](https://www.youtube.com/watch?v=FRogt98OF80)
##### Et pour découvrir de nouveaux sujets, n'hésitez pas à consulter nos derniers articles publiés !
- [Du code au coeur : nos engagements associatifs annuels](/fr/blog/articles/du-code-au-coeur-nos-engagements-associatifs-annuels)
- [Léa English : Étude de cas UX](/fr/blog/articles/lea-english-etude-de-cas)
- [Le bon et le mauvais développeurs : les soft skills](/fr/blog/articles/le-bon-et-le-mauvais-chasseur-developpeur-les-soft-skills)
Auteur : Noé Tatoud
[LinkedIn](https://www.linkedin.com/in/noetatoud/) - [X](https://twitter.com/nowaytatoud) - [Github](https://github.com/ntatoud)
---
### Du code au cœur : nos engagements associatifs annuels
URL: https://www.bearstudio.fr/fr/blog/articles/du-code-au-coeur-nos-engagements-associatifs-annuels
Date: 2025-07-22
## Un engagement associatif ancré dans notre culture
Au BearStudio, les engagements associatifs font partie de notre culture. En plus du développement, du design et de la formation, nous avons aussi un rituel important qui nous tient à cœur : les dons aux associations !
Ces dons aux associations se veulent collaboratifs. Chaque année, en Octobre, un appel est fait aux membres du BearStudio et ceux qui gravitent autour, pour que chacun ait l’occasion de présenter une association qui lui est chère. C’est ainsi que, depuis 2020, une vingtaine d’associations a été mise en avant afin qu’une donation puisse être effectuée.
## L’origine de notre démarche solidaire
##### Une idée née d'une augmentation… différente
Tout a commencé avec Quentin il y a quelques années, l’un de nos collaborateurs. Lors d’une réunion d’augmentation autour d’une pizza (on vous invite à lire [cet article](https://ppbearstudio.wpengine.com/blog/entrepreneuriat/comment-deleguer-la-responsabilite-pour-les-augmentations) sur notre processus d'augmentation), Quentin a fait une demande atypique. Une fois n’est pas coutume, s’étant renseigné sur l’impact financier de son augmentation, il a souhaité l’utiliser en deux temps :
- Dans un premier temps, il a demandé à BearStudio de recruter un stagiaire pour faire avancer son side project : [TraveledMap](https://www.traveledmap.com/fr).
- Dans un second temps, il a souhaité soutenir une association par le biais d’une donation en fin d’année.
C’est pourquoi, durant 2 ans, le BearStudio a versé le montant équivalent à son augmentation aux causes qu’il souhaitait. Suite à cette initiative portée par Quentin au départ, BearStudio a désiré pérenniser l’action. C’est ainsi que depuis 2020 l’entreprise a effectué 24 donations à différentes associations pour une valeur proche de 35 000€.
## Zoom sur quelques associations soutenues
##### Atelier Sainte Claire
[Atelier Sainte Claire](https://rouen.fr/associations/ateliers_sainte_claire) _est une association qui aide des adultes en situation de handicap psychique._ Ce don a permis l’installation de deux ruches dans les Ateliers Sainte Claire à Rouen. Ce qui a permis de récolter environ 20 kg de miel sur l’année.


##### France Parrainage
Au Pérou dans la ville d’Abancay, [France Parrainage](https://www.france-parrainages.org/international/decouvrez-dans-quel-pays-parrainer?gad_source=1&gclid=Cj0KCQiAsaS7BhDPARIsAAX5cSB-Tx2KsE0L9Be3lttG9_5u90Dupw64eTIM8K-ra_TwfxnCI0RLMW0aAslGEALw_wcB) a mis en place une aide alimentaire à des étudiants en difficultés suite à la pandémie. En Inde, ce don permet d’aider des jeunes démunis dans leur scolarité. Au total, les dons ont permis d’aider des familles et leurs enfants issus de contextes socio-économiques et familiaux difficiles.
##### Mécénat Cardiaque
[Mécénat Cardiaque](https://mecenat-cardiaque.org/) est une association qui a pour but d’aider les enfants atteints de malformations cardiaques d’être opérés lorsque cela est impossible dans leur pays, faute de moyens techniques ou financiers. Ils sont alors pris en charge dans 11 villes françaises, 2 villes suisses ou 1 ville espagnole. Ils sont hébergés par des familles d’accueil bénévoles et en Suisse parfois dans une maison spécialisée.
##### Association Delfina
[Association Delfina](https://www.associationdelfina.fr/) _a pour but de venir en aide aux populations défavorisées en Afrique._
Madagascar : Amélioration des locaux d’éducation du collège Marovantaza et également d’installer 6 panneaux solaires. Approfondissement du puits de Pont Banty pour atteindre le niveau de l’eau qui a baissé. Fourniture de livres de lecture, de matériels scolaires et d’équipements pour l’établissement scolaire.


##### Maromme Canteleu Volley
[Maromme Canteleu Volley](https://mcv76.fr/) est le club de Volley-ball dans lequel [Soraya](/fr/equipe/soraya-benchakroune) a commencé sa “carrière” de Volleyeuse. Bénévole pendant de nombreuses années et évoluant dans ce club depuis plus de 3 ans. Elle a souhaité que le don du BearStudio serve à acheter des ballons et des accessoires pour l’organisation des séances d'entraînement. Ainsi permettre aux jeunes joueurs de pouvoir être le mieux encadrés.

##### Rouen Handball
Compétiteur né, Quentin reprend le Handball en dernière division après quelques années d’arrêt. Il reprend les armes au sein du club [Rouen Handball](https://www.rouen-handball.fr/) qui évolue jusqu’en N1 Féminine et Masculine. Quentin, souhaitant représenter le BearStudio jusque dans les gymnases, a demandé un don qui a permis à son équipe de se fournir en équipements.

##### Foot Tourvilles sur Arques
[Foot Tourvilles sur Arques](https://tourville-sur-arques.footeo.com/) est le club d’un de nos deux [Hugo](/fr/equipe/hugo-perard) préféré. Il y a évolué depuis l’âge de 6 ans (soit presque 18 ans), où il a pu se former au poste de défenseur. BearStudio a pu soutenir son club notamment dans l’achat de matériel et d’ensembles de survêtements.

## L’impact de ces contributions
Ces contributions offrent aux collaborateurs de BearStudio l’occasion de s’engager dans des causes qui leur tiennent à cœur. En plus des bénéfices concrets qu’elles apportent aux associations soutenues, elles permettent également à BearStudio de profiter d’une réduction fiscale prévue par l’État français.
## Le mécénat de compétences : un nouveau pas vers l’engagement
Cette année, au BearStudio, nous avons également commencé le bénévolat par le mécénat de compétences, à savoir offrir des heures de savoir-faire au service d’associations en demande. C’est le cas de [Nhung](/fr/equipe/nhung-duong) et [Ivan](/fr/equipe/ivan-dalmet) qui œuvrent pour [Sistech](https://sis.tech/donation-sistech-refugee-women/). Sistech soutient l’émancipation professionnelle des femmes réfugiées dans les métiers de la tech et du numérique en France, en Italie et en Grèce. Nhung est présente pour les aider sur le côté administratif et business, tandis qu’Ivan les aide en discutant et pratiquant le français afin qu’elles puissent s’améliorer et le pratiquer le plus souvent possible.
Quentin, lui aussi aide l’association Passerelle Numérique au Vietnam, dont l’objectif est de sélectionner (sur la base de leur niveau et de la précarité de leurs familles) des futurs étudiants pour financer leurs 3 années d’études dans l’informatique. Quentin donne deux ateliers différents l’un basé sur l’infrastructure distribuée et l’autre sur le thème de l’utilisation de l’IA dans les métiers du numérique.
## Ensemble, pour une action durable
En tant que salariés de BearStudio, nous sommes fiers de contribuer à des projets qui font la différence pour certains. Ensemble, nous espérons continuer à soutenir des associations et des clubs, tout en explorant de nouvelles façons de redonner à la communauté.
Si vous connaissez une association alignée avec nos valeurs, nous serions ravis d’en discuter avec vous !
---
### Lea English étude de cas
URL: https://www.bearstudio.fr/fr/blog/articles/lea-english-etude-de-cas
Date: 2025-07-03
## Présentation du projet
Lea English est une plateforme d’apprentissage en ligne créée par Léa, **coach linguistique professionnelle** multilingue parlant couramment cinq langues. Elle rassemble une communauté de plus de **350 000 apprenants francophones.** Son approche pédagogique, quant à elle, met l’accent sur l’apprentissage efficace de l’anglais courant à travers des compétences conversationnelles concrètes.
Contrairement aux cours traditionnels centrés sur la grammaire, ou aux applications excessivement gamifiées, son approche minimaliste privilégie les compétences orales essentielles et l’usage naturel de la langue. **L’objectif est d’atteindre une aisance rapide et concrète.**
Forte d’une application **web éprouvée et des retours de ses utilisateurs payants,** Léa s’est associée à notre équipe. Ce qui a permis de faire évoluer cette expérience d’apprentissage grâce à **une application mobile** pensée avec soin et centrée sur les besoins des utilisateurs.
## Le Défi / Contexte
Les apprenants en langues sont souvent confrontés à des programmes **surchargés** et **axés sur la grammaire,** ce qui limite leurs progrès en conversation. D’autres méthodes, à l’inverse, misent trop sur la **gamification au détriment de l’efficacité.**
**Les applications traditionnelles** ciblent généralement **les débutants,** sans vraiment permettre de passer efficacement à un niveau intermédiaire ou avancé.
Par ailleurs, **les apprenants manquent** fréquemment de pratique dans des **conversations concrètes** et rencontrent des **difficultés à communiquer** avec assurance dans des **situations réelles.**
## Notre rôle - BearStudio
##### Product designer (UI/UX Designer), en charge de :
- **Recherche utilisateur** (entretien avec des experts, retours d’utilisabilité, analyse de concurrence)
- **L’architecture de l’information** et **parcours utilisateurs**
- **Wireframing** et le **prototypage**
- **Tests d’utilisabilité** et **itérations de conception**
- **Collaboration itérative** avec **les développeurs** sur les défis techniques et la faisabilité des idées
##### Les Développeurs :
- **Développement** de l’application en React Native / Expo, pour un déploiement sur Android et iOS
- **Conception** **d'animations** pour agrémenter l'application
- **Mise en place** de la fonctionnalité de bot conversationnel (basée sur l’API d’OpenAI)
- **Intégration** **des retours** du product designer et de Léa
- **Utilisation** **des composants** partagés depuis Storybook et Figma pour garantir cohérence et efficacité dans l’interface
## Recherche & informations clés
#### Atelier de lancement
Pour tirer pleinement parti de la connaissance approfondie que notre cliente a de ses utilisateurs, nous avons tenu un **atelier collaboratif ciblé de 3 heures avec Léa**. Elle y a partagé de **nombreux retours,** directement recueillis auprès de **ses utilisateurs**. Ces données sont riches et qualitatives. Elles proviennent de l’expérience de terrain de Léa et de ses échanges directs avec **plus de 350 000 apprenants engagés.** Grâce à ces informations, nous avons pu identifier rapidement **les besoins clés** des utilisateurs. De plus, elles ont permis de valider les principaux points de friction rencontrés. Nous avons esquissé **les premières pistes en temps réel,** à mesure que les idées émergeaient, nourries par l’expérience précieuse de Léa dans l’enseignement.

Esquisse générale de notre atelier en ligne avec la cliente
Nous avons complété ces précieuses données fournies par la cliente par une **analyse comparative** ciblée de la concurrence (en étudiant des plateformes comme Duolingo, iTalki ou Simpler). [Ce qui nous a permis d’identifier des bonnes pratiques UX spécifiques ainsi que des axes d’amélioration.](/fr/blog/articles/pourquoi-lexperience-utilisateur-est-elle-importante) Cette démarche nous a permis de renforcer les bases solides posées par Léa. Nous avons combiné ses retours centrés sur les utilisateurs avec les standards du secteur. Grâce à cela, nous avons pu définir clairement une orientation forte pour notre travail de design.
#### Détails supplémentaires sur les données initiales et la recherche
##### Analyse de la concurrence
Pour mieux comprendre le marché, nous avons étudié plusieurs plateformes telles que Duolingo (excellente gamification, peu de pratique orale), iTalki (tuteurs en direct, mais planification et contenu des cours pouvant sembler fragmentés), et Simpler (vise principalement les débutants via une approche grammaticale, ce qui ne favorise pas des résultats rapides en communication quotidienne).
De cette analyse concurrentielle, il est ressorti que l’application à concevoir devait faire preuve **d’efficacité** en imitant la méthode d’enseignement de notre cliente et en améliorant le **feedback en temps réel**. Les cours particuliers étant souvent coûteux ou peu flexibles, notre objectif était de créer une solution intégrée combinant le meilleur des deux mondes : des leçons interactives en ligne et des exercices à la demande, tout en maintenant un format engageant, mais aussi **orienté résultats**.
##### Retours utilisateurs sur sa première version de l’application web
**Plus de 400 apprenants** ont participé aux retours via des sondages, révélant plusieurs points de friction :
- **Fonctionnalités manquantes** \- Les utilisateurs ont formulé des suggestions claires pour améliorer leur routine d’apprentissage sur l’app déjà existante.
- **Motivation et régularité** \- beaucoup peinent à rester constants sans indicateurs concrets de progression et sans fonctionnalité de notification.
**Notre analyse** approfondie de **l’application web**, croisée avec les retours des **utilisateurs payants** réguliers, a mis en lumière plusieurs points de friction :
- **Charge cognitive élevée**, rendant l’usage parfois fatigant ou décourageant.
- **Manque de fluidité** dans les parcours utilisateurs, nuisant à l’expérience globale.
- **Problèmes d’ergonomie**, avec des interactions clés jugées peu intuitives ou inutilement complexes.
Ces obstacles réduisaient significativement l’engagement et l’accessibilité. Au-delà des problématiques UX, nous avons également identifié **des failles techniques, dont des vulnérabilités de sécurité et des bugs fonctionnels récurrents**.


##### Quelques-unes de nos observations
- **Clics excessifs dans les tests -** les utilisateurs devaient enchaîner plusieurs clics pour passer à l’étape suivante, ce qui ajoutait des lenteurs inutiles et nuisait à la fluidité du parcours.
- **Expérience audio asynchrone -** la transcription ne mettait pas en surbrillance les mots en temps réel pendant la lecture, rendant le suivi difficile pour les utilisateurs.
- **Interaction limitée avec les flash cards -** le mécanisme de retournement était peu intuitif et ne favorisait pas une expérience d’apprentissage fluide et continue.
#### Public cible
- Apprenants adultes allant de très **débutants (A1) à avancés (C1).**
- Utilisateurs préférant un apprentissage **pratique et efficace**, plutôt que centré sur la grammaire.
- Personnes souhaitant développer leur aisance à l’oral grâce à une **pratique régulière, interactive et axée sur la conversation.**
Nous nous sommes assurés que les décisions de design étaient alignées avec **les besoins réels des utilisateurs**. En cartographiant les comportements, objectifs et frustrations des utilisateurs, la recherche a permis une meilleure compréhension des limites de la première version de l’application. Ces limites concernaient surtout l’ergonomie et la capacité à maintenir l’engagement des utilisateurs. Par ailleurs, cette analyse a servi de référence tout au long du processus de conception. Elle a aidé à prioriser les améliorations nécessaires. Celles-ci visaient à enrichir l’expérience globale, fluidifier les interactions et accroître la satisfaction des utilisateurs.
## Approche claire : principes directeurs et bénéfices
##### Intégration fluide pour renforcer l’apprentissage
Le vocabulaire, l’audio et les exercices interactifs sont **étroitement liés**, créant un écosystème cohérent. Les utilisateurs renforcent ainsi naturellement leurs compétences grâce à des **interactions variées** et **connectées,** favorisant une mémorisation et une assimilation efficaces.
##### Expérience d’apprentissage personnalisée
En s’appuyant sur le niveau, les préférences et les comportements de l’utilisateur, l’application propose constamment du contenu et des interactions sur mesure, renforçant considérablement la motivation et l’efficacité de l’apprentissage. Ce qui mène à une **personnalisation centrée sur l’utilisateur**.
##### UX intuitive et engageante
Privilégier des interactions simples, claires et intuitives assure une charge cognitive minime, permettant aux utilisateurs de se concentrer pleinement sur l’apprentissage de la langue plutôt que sur la navigation. L'intégration d'interactions gamifiées, de limites journalières, d'indicateurs de progrès clairs et de retours immédiats motive les utilisateurs à poursuivre une pratique régulière de la langue. Ce qui conduit à une **motivation d’apprentissage continue**.
##### Une approche flexible et accessible à tous les niveaux
Tout en s’adressant à un large public, l’application permet aux utilisateurs de choisir leur type d’apprentissage, tout en suivant une progression définie pour atteindre le niveau suivant. Ce qui mène à un **engagement prolongé sur la plateforme**.
## Conception & itération
#### Premiers wireframes
Nous avons utilisé les wireframes pour définir les fonctionnalités de l’application et structurer ses principales sections ainsi que son architecture de l’information.
- **Cartes Interactives** - un court test pour assurer l’intuitivité du geste pour les utilisateurs dès le départ.
- **Écoute audio** - test de l’accès rapide aux niveaux audio souhaités par l’utilisateur.
- **Chat IA** - test de la clarté de distinction pour les utilisateurs entre la conversation du jour, interactive, et les conversations passées, qui doivent être clairement indiquées comme inactives.

#### Tests d’utilisabilité et validation
Nous avons mené des sessions internes de **tests d’utilisabilité** avec **six collègues**. Ces tests portaient sur des wireframes basse fidélité. Nous nous sommes concentrés sur des scénarios basés sur des tâches. L’objectif était d’évaluer rapidement la clarté des interactions, l’intuitivité de la navigation et l’engagement global. Ces retours ont permis d’alimenter des itérations rapides du design.
L’un des **ajustements** a concerné le comportement des cartes, avec l’ajout du bouton «Ne pas apprendre», demandé par les utilisateurs pour les cas où ils ne souhaitaient plus pratiquer un mot ou une expression.
## Conception expliquée
#### Branding et design system
Lea English disposait déjà **d’une identité visuelle** claire et bien définie, que nous avons intégrée naturellement dans notre design system personnalisé. Nous nous sommes appuyés sur les composants issus de [Start UI Figma](/fr/blog/articles/start-ui), une bibliothèque open-source pour Figma que nous avons conçue et utilisons en interne.
Les composants que nous utilisons dans Figma sont déjà implémentés dans [Start UI Native](/fr/blog/articles/start-ui). Cette bibliothèque utilise des technologies comme **TypeScript, React** et **Ficus UI.** Grâce à cela, les développeurs peuvent accélérer immédiatement la phase d’implémentation après la finalisation du design. Par ailleurs, cela garantit une cohérence pour les futures fonctionnalités à venir.

#### Analyse des fonctionnalités UX
###### 1\. Cartes de vocabulaire quotidiennes
- **Cartes Interactives à Retourner**
- Les utilisateurs interagissent via un **geste intuitif de retournement** pour **révéler la traduction**, ce qui renforce la mémorisation active, une technique d’apprentissage éprouvée.
- L’interaction de retournement stimule immédiatement l’attention cognitive, favorisant une **meilleure mémorisation.**
- **Limite Quotidienne**
- **La restriction** à 5 cartes par jour permet de gérer la charge cognitive, **d’éviter la fatigue** et d’améliorer **la mémorisation à long terme.**
- Cela introduit **un élément de gamification,** créant de l’anticipation et la mise en place d’une routine quotidienne.
- **Indicateur de Progression**
- Des compteurs ou barres de **progression** clairement visibles encouragent l’engagement régulier des utilisateurs et fournissent un **retour immédiat** sur les objectifs atteints dans la journée.

###### 2\. Fonctionnalité “Réviser”
- **Listing Synchronisé**
- Les mots retournés dans les cartes quotidiennes **apparaissent automatiquement** dans la section de révision. Ceux-ci sont clairement indiqués selon l’interaction de l’utilisateur (vert pour connu, rouge pour inconnu).
- Cette synchronisation assure une **intégration fluide** entre l’apprentissage et la révision du vocabulaire, **renforçant l’assimilation.**
- **Gestion personnalisée du vocabulaire**
- Les utilisateurs peuvent ajouter manuellement de nouveaux mots pour **personnaliser leur liste de vocabulaire,** améliorant la personnalisation de leur expérience d’apprentissage.
- Des options telles que marquer un mot comme “connu” ou le supprimer avec “ne plus apprendre” permettent une **gestion efficace des mots** à travailler.
- **Options de présentation flexibles**
- Les utilisateurs peuvent choisir d’afficher les mots d’abord en français ou en anglais, selon leurs **préférences** d’apprentissage.
- **Audio et Exemples**
- Les utilisateurs peuvent **écouter la prononciation** directement dans la section de révision, soutenant l’apprentissage auditif.
- Des exemples de mots ou expressions contextualisés aident à renforcer la compréhension et l’usage correct.

###### 3\. Fonctionnalité “Écouter”
- **Recommandations audio personnalisées**
- Les audios suggérés sont mis en avant en haut de l’écran selon **le niveau d’anglais** de l’utilisateur (débutant, intermédiaire, avancé), assurant la pertinence du contenu.
- Chaque audio est clairement étiqueté selon le niveau de langue, le type (dialogue ou monologue) et le thème général, facilitant ainsi une sélection rapide et éclairée.
- **Suivi visuel de la progression**
- Les audios déjà écoutés sont indiqués en vert, offrant un retour visuel immédiat sur la progression de l’utilisateur.
- **Filtrage avancé**
- Les utilisateurs peuvent filtrer les audios par favoris, téléchargements hors ligne et niveaux, permettant une personnalisation efficace des sessions d’écoute.
- **Fonctionnalités d’accès rapide**
- Les options de téléchargement rapide et de mise en favori (cœur) sont directement accessibles depuis la liste des audios, simplifiant les interactions et améliorant l’ergonomie.
- **Écran audio détaillé**
- Des boutons d’action rapide pour télécharger, ajouter aux favoris ou marquer comme écouté offrent un usage plus pratique.
- Les transcriptions interactives permettent de basculer instantanément entre l’anglais et le français, avec un surlignage synchronisé du texte pour accompagner la lecture et l’écoute.
- Le nouveau vocabulaire dans les transcriptions est mis en évidence en majuscules et en gras, afin d’en faciliter la reconnaissance immédiate et l’apprentissage.
- **Barre de contrôle audio fixe**
- Les contrôles audio restent visibles en permanence pendant le défilement, avec des options intégrées pour régler la vitesse de lecture et afficher ou masquer la transcription, améliorant ainsi le confort et le contrôle de l’utilisateur.

###### 4\. Conversation avec l’IA : “Pratiquer”
- **Sessions de conversations IA quotidiennes**
- Les utilisateurs participent chaque jour à des conversations guidées avec une IA autour de sujets prédéfinis. Cette pratique encourage l’utilisation active de la grammaire et le développement des compétences conversationnelles.
- Des corrections en temps réel fournies par l’IA offrent un retour immédiat, permettant aux utilisateurs d’identifier rapidement leurs erreurs et d’en tirer apprentissage.
- L’utilisateur a un accès rapide à un traducteur pendant la conversation.
- **Mise en évidence des erreurs**
- Les fautes de grammaire ou de syntaxe sont clairement signalées et corrigées pendant les échanges, aidant les utilisateurs à intégrer les structures linguistiques correctes.
- **Sujets quotidiens structurés**
- Des thèmes variés chaque jour garantissent une exposition riche à différents vocabulaires et contextes grammaticaux, gardant l’exercice pertinent et motivant.

#### Gestion complète du lancement et conception visuelle
En préparation de la sortie publique, nous avons conçu l’ensemble des éléments visuels. Cela inclut des **aperçus détaillés de l’application**, optimisés pour différents formats d’appareils sur **l’App Store et Google Play.** Par ailleurs, nous avons géré en interne **tout le processus de lancement.** Nous avons ainsi garanti une représentation cohérente de la marque. De plus, nous avons assuré une prise en main fluide pour les utilisateurs, sur toutes les plateformes.
#### Lancement itératif et intégration des fonctionnalités
La sortie initiale, **en avril 2025,** a stratégiquement ciblé environ **300 utilisateurs** dès le jour du lancement, afin de constituer un environnement de test contrôlé. Ces premiers retours ont été d’une grande valeur, nous permettant d’itérer rapidement et d’améliorer [l’expérience utilisateur](/fr/blog/articles/pourquoi-lexperience-utilisateur-est-elle-importante) en nous appuyant sur des retours directs.
###### Personnalisation du rythme d’apprentissage
Les utilisateurs ont demandé une fonctionnalité permettant **de choisir le nombre de nouvelles cartes à retourner chaque jour**, afin d’adapter leur apprentissage à leur propre rythme.
###### Fonction speech-to-text
Les utilisateurs ont également demandé **une fonctionnalité de reconnaissance vocale** pour les conversations générées par l’IA, qui a été conçue et intégrée avec succès.
###### Expansion géographique
Les retours de la communauté ont révélé **une demande dans d’autres régions**. Nous avons donc élargi la disponibilité de l’application à plusieurs pays en plus de la France, notamment le Maroc, la République Démocratique du Congo, le Canada, les États-Unis, le Royaume-Uni et l’Allemagne.
Retours sur le lancement:

#### Résultats après lancement - premier mois
La nouvelle application mobile a vu un fort engagement utilisateur dès son premier mois. **Plus de 2 000 installations** sur les plateformes Android et iOS
###### Répartition des abonnements
- Abonnements mensuels : environ **60 % des utilisateurs** ont opté pour un **abonnement mensuel**, la majorité commençant par un essai gratuit.
- Abonnements annuels : environ **30 % des utilisateurs** ont choisi une **formule annuelle**, témoignant d’une forte confiance et d’un engagement durable.
- Abonnements intermédiaires (6 mois) : environ **10 % des utilisateurs** ont préféré cet **engagement intermédiaire**.
###### Informations spécifiques aux plateformes
Ce schéma de répartition des abonnements met en lumière **le succès de l’onboarding et de la stratégie d’abonnement,** indiquant que l’UX a su communiquer efficacement la valeur du produit et encourager un engagement sur le long terme.
Retours trouvés sur AppStore/ Google Play/ Trustpilot :





## Réflexions finales
Au vu des données recueillies, nous pensons avoir réussi à concevoir **une application efficace.** Celle-ci intègre les principes de la psychologie cognitive. Elle propose aussi des interactions UX conviviales et engageantes. En combinant une navigation intuitive avec des éléments d’apprentissage interactifs, elle offre une expérience utilisateur personnalisée. Grâce à cela, notre application favorise u**ne pratique régulière et une motivation durable.** Elle permet aussi des progrès significatifs dans l’apprentissage de l’anglais pour les apprenants francophones.
Vous pouvez consulter **le prototype interactif Figma ici** → [LINK](https://www.figma.com/proto/OfWcem6ytSSSAvaeP9nnOv/%F0%9F%91%A9%F0%9F%8F%BB%E2%80%8D%F0%9F%8F%AB-Lea-English?page-id=1453%3A591&node-id=1562-4425&p=f&viewport=226%2C167%2C0.05&t=8uDnG5QbLEdpTfjn-9&scaling=scale-down&content-scaling=fixed&starting-point-node-id=1562%3A4425&show-proto-sidebar=1)
---
### Le bon et le mauvais développeur : Les soft skills
URL: https://www.bearstudio.fr/fr/blog/articles/le-bon-et-le-mauvais-chasseur-developpeur-les-soft-skills
Date: 2025-06-30
_Le mauvais développeur c’est le gars, il a un ordinateur, on lui donne des specs et il code. Le bon développeur il a un ordinateur, on lui donne des specs et il code… mais c’est un bon développeur…_
Au-delà de sa capacité technique, qu’est-ce qui différencie réellement un bon et un mauvais développeur ? Je vais tenter de donner des exemples concrets permettant de répondre à cette question.
Lorsqu’on parle de compétences mais qu’on exclut l’aspect technique, on parle de ce qu’on appelle des **soft skills**. Un soft skill est donc une compétence basée sur l’attitude d’une personne au jour le jour, ou face à une situation particulière.
Cette notion est très large, elle inclut par exemple la communication, la gestion du temps, la collaboration, etc., elle ne s'applique pas uniquement au métier de développeur. Cela dit, nous allons aujourd'hui nous concentrer sur les soft skills essentiels dans ce domaine.
Pour illustrer cela, comme vous l’avez peut-être compris par le titre de cet article, je vais utiliser la fameuse explication du bon et du mauvais chasseur, en essayant d’être un peu plus convaincant 😂.
Pour ce faire, je vais donner des cas concrets ainsi qu’un petit parallèle un peu absurde pour expliciter l’importance des soft skills et en sortir des conseils et des bonnes pratiques.

L’IA a un peu abusé sur le mauvais développeur... 😂
## Le wording
On commence avec un cas qui touche tous les développeurs qui peut paraître sans réel intérêt à première vue mais qui en réalité fait la différence, c’est bien évidemment le wording. Le wording (soit le nommage) est présent à plusieurs endroits pour un développeur, du nom des variables, à la description des commits et des merge requests…
Je vais utiliser le cas du nom des variables comme cas concret.
##### Le mauvais développeur
Il va nommer une variable d’une façon pas ou peu explicite :
```javascript
const v = () => [...] // Là j’abuse mais ça existe
```
```javascript
const values = () => [...]
```
##### Le bon développeur
Il contextualise son wording afin d’expliciter le plus clairement possible ce dont il s’agit :
```javascript
const getFormValuesSortedByName = () => [...]
```
##### Parallèle
C’est comme dire à son coloc j’ai mis un truc pour toi dans le frigo, et en ouvrant le frigo il se rend compte que c’est plein et tout en vrac, donc il ne sait pas ce qu’est le truc pour lui.
##### Conseils
Il faut se mettre à la place de quelqu’un qui découvre le code et voir si c’est compréhensible et avec un minimum d’ambiguïté pour permettre une compréhension plus efficace. (Se mettre à la place de son futur soi fonctionne aussi 😅).
D’autres questions qu’il peut être bien de se poser :
- Est-ce que c’est grammaticalement correct ?
- Est-ce que cela suit les conventions globales et du projet ? Par exemple si la convention définie sur le projet est de traduire les termes techniques en anglais alors respecter cette règle sur ses développements.
## Demande de l’aide (partie 1 / 2)
Lorsqu’on rencontre un problème qui nous bloque, il est crucial de savoir quand chercher seul et quand demander de l’aide.
##### Le mauvais développeur
Il passe des heures à essayer de résoudre un problème sans demander de l’aide, ou à l’inverse, il pose une question sans avoir fait les recherches de base.
##### Le bon développeur
Il prend le temps de faire ses propres recherches avant de solliciter les autres. Ainsi, il fournit des informations de base qui pourront aider une autre personne à solutionner le problème. Il sait aussi demander de l’aide au bon moment, en posant une question claire et bien formulée. Enfin, il est capable de juger l’importance du problème et de prioriser ses tâches si besoin.
##### Parallèle
C’est comme demander à quelqu’un de monter un meuble sans même avoir regardé la notice.
##### Conseils
Avant de demander de l’aide, pose-toi les questions suivantes :
- Ai-je cherché une solution de manière autonome avant de solliciter quelqu’un ?
- Est-ce que ma question est suffisamment claire et précise pour que l’on puisse m’aider efficacement ?
- Est-ce que la correction de mon problème vaut le temps que je suis en train de passer dessus ? Est-ce que je ne pourrais pas passer du temps sur quelque chose de plus important ?
## Demande de l’aide (partie 2 / 2)
La façon dont on formule une demande d’aide peut faire toute la différence dans la rapidité et l’efficacité de la réponse.
##### Le mauvais développeur
Il envoie des messages vagues du type : “Ça marche pas, j’ai une erreur”, sans fournir d’informations utiles pour résoudre le problème.
##### Le bon développeur
Il envoie un message clair et détaillé, en contextualisant sa situation et en fournissant les informations clés sur l’erreur rencontrée. Cela comprend par exemple l’environnement, les étapes précédant le problème, etc.
##### Parallèle
C’est comme appeler un plombier en disant juste “y’a de l’eau partout” sans préciser d’où ça vient.
##### Conseils
Pour faciliter l’aide que vous recevrez, prenez le temps de bien expliquer votre problème. Vous gagnerez du temps et recevrez une réponse plus précise et rapide.
- Quelles sont les étapes qui ont conduit à l’erreur ?
- Quelles erreurs ou messages avez-vous obtenus ?
- Quel comportement attendu cherchiez-vous à obtenir ?
- Qu’est-ce que vous avez déjà essayé de faire pour corriger le problème ?
Selon le problème il peut-être également pertinent de faire du [peer programming](/fr/blog/articles/peer-programming) avec un développeur plus expérimenté.
## Tests
Les tests sont une étape essentielle dans tout développement, s’en passer peut causer une perte de temps et une frustration pour toute l’équipe.
##### Le mauvais développeur
“Tester c’est douter”, ou au mieux il teste uniquement en local dans un contexte favorable.
##### Le bon développeur
Il est garant de son développement. Il teste en local avant de soumettre à la review mais aussi sur les environnements pour s’assurer qu’aucun souci n’est apparu. Et il élargit ses tests pour assurer que son développement n’a pas d’impacts dans différents cas fonctionnels ou d’autres écrans si son développement est commun à plusieurs écrans.
##### Parallèle
C’est comme ci le groupe Ariane avait mit des spationautes dans leur nouvelle fusée sans avoir fait des dizaines de tests avant.
##### Conseils
Il faut s’assurer que son développement répond fonctionnellement à 100% de la demande initiale, mais pas seulement. Il faut également mesurer les impacts de celui-ci afin de limiter les probabilités de régressions.
- Est-ce que mon développement répond à la spécification ?
- Est-ce que mon développement touche d’autres fonctionnalités ? Si oui est-ce qu’elles sont toujours fonctionnelles ?
## Collaboration
Dans le monde professionnel, un développeur travaille rarement seul sur un projet du début à la fin. D'autres personnes interviendront tôt ou tard, peut-être même de façon temporaire. Cela peut être le cas par exemple pour de l'intérim en remplacement de congés. C’est pourquoi il est essentiel de faciliter la collaboration.
##### Le mauvais développeur
Il développe sans documenter aucune décision fonctionnelle ou technique, process ou choses à savoir. Il est le seul à avoir la connaissance sur des sujets spécifiques; son absence est en général problématique car souvent bloquante pour le reste de l’équipe qui est devenue dépendante de son savoir fonctionnel ou technique.
##### Le bon développeur
Il laisse des traces des réflexions et des choix fait sur le projet, qu'ils soient techniques mais aussi fonctionnels, et documente des process, par exemple pour la mise en place ou le déploiement du projet.
##### Parallèle
C’est comme si on construisait une ville sans laisser aucun plan, donc lorsqu’on devra venir faire des travaux on aura aucune idée de ce qu’il y a, où et pourquoi.
##### Conseils
Il faut se dire que si vous vous posez des questions, quelqu’un d’autre (et spoiler, sûrement même votre futur vous) se posera ces mêmes questions et sera donc très heureux de trouver une réponse. Si vous ne voulez pas être dérangé pendant vos vacances, documentez vos connaissances ! (La documentation ça va de simples commentaires dans le code à de la documentation externe en passant par le README).
## Gestion des priorités
Le développeur peut avoir plusieurs tâches de prévues, que ce soit un unique projet ou sur plusieurs, ou des tâches annexes au sein de son entreprise par exemple.
##### Le mauvais développeur
Il passe 2 jours sur un bug mineur sans avancer sur le reste, il se noie dans des tâches sans importance et ignore les deadlines. À la fin d’un sprint, on se retrouve avec un wording corrigé et un layout parfait sur tous les appareils, mais la fonctionnalité attendue n’est pas présente.
##### Le bon développeur
Il sait identifier ce qui est prioritaire ou bien demander à un décideur (le Product Owner par exemple) ce qui est prioritaire, il découpe son travail en tâches gérables et ajuste ses efforts en fonction de l’impact et de la valeur des tâches.
##### Parallèle
C’est comme faire le ménage en commençant par trier ses chaussettes alors que la cuisine est en feu.
##### Conseils
Deux bonnes méthodologies qui peuvent être suivies pour aider à mieux gérer les priorités :
- [La matrice d’Eisenhower](https://fr.wikipedia.org/wiki/Matrice_d%27Eisenhower)
- [La règle des 2 minutes de David Allen](https://www.gqmagazine.fr/article/la-regle-des-2-minutes-tout-savoir-sur-cette-methode-ultra-simple-qui-permet-d-etre-moins-stresse-et-plus-productif)
Ces deux idées peuvent être combinées afin d’aider à mieux gérer de déterminer l’ordre de priorité de ses tâches.
## Division des tâches
Pour une meilleure collaboration, une analyse externe plus performante mais aussi pour une maintenabilité plus efficace, il est important de séparer distinctement ses développements.
##### Le mauvais développeur
Il ouvre une unique merge request avec un unique commit contenant 200 fichiers modifiés, incluant des correctifs, des nouvelles fonctionnalités et des changements d’arborescence des fichiers (pour rendre le tout bien illisible).
##### Le bon développeur
Il sépare ses développements en plusieurs merge requests (bien nommées), une pour des correctifs, avec plusieurs commits pour les différents correctifs, une pour l’ajout d’une fonctionnalité, etc..
##### Parallèle
C’est comme si lors d’un déménagement au lieu de trier ses affaires et écrire sur les cartons ce qu’il y a à l’intérieur on mettait tout en vrac dans un énorme carton. Bon courage ensuite pour retrouver un objet précis ou savoir où chaque chose est censée aller une fois arrivé à destination.
## Savoir dire non, et expliquer pourquoi
Un développeur doit pouvoir conseiller pour aider le projet sur lequel il travaille, et savoir orienter le décideur sur des choix pour éviter des problèmes est une partie de ce travail de conseil.
##### Le mauvais développeur
Il accepte toutes les demandes sans réfléchir aux impacts, se retrouve submergé et livre un travail bâclé, ou ne livre rien du tout.
##### Le bon développeur
Il évalue la faisabilité d’une demande, explique les contraintes techniques et propose des alternatives réalistes.
##### Parallèle
C’est comme si un restaurateur acceptait toutes les commandes, même s’il n’a pas les ingrédients, et finit par servir n’importe quoi.
##### Conseils
Il faut prendre en compte le contexte du projet pour estimer si la demande est réalisable et sinon proposer des alternatives qui le sont. Il n’est jamais trop tard pour remonter qu’une demande est irréalisable : il vaut mieux stopper une tâche qui est partie dans une mauvaise direction, que de continuer à s’enfoncer et finir avec une solution peu satisfaisante qui aura pris énormément de temps.
## Challenger des spécifications
Il se peut que des spécifications soit inexactes ou même fausses, le développeur doit comprendre ces spécifications et être capables de détecter des erreurs “visibles” (des spécifications très fonctionnelles sont complexes et des erreurs sont difficilement détectables).
##### Le mauvais développeur
Il traite un sujet où les spécifications disent que 1 + 1 = 3, alors il développe que 1 + 1 = 3.
##### Le bon développeur
Il sait que 1 + 1 = 3 est faux, alors il se questionne pour bien comprendre les spécifications, puis rapporte ses questions au décideur pour voir s’il s’agit d’une erreur.
##### Parallèle
C’est comme un cuisinier qui suit une recette sans se demander si le client est allergique à un ingrédient.
##### Conseils
Il est important de comprendre au maximum le fonctionnel, déjà pour s’assurer du résultat du développement, mais aussi pour pouvoir remonter de possibles incohérences ou même proposer des alternatives. Pour ça il faut poser des questions pour s’assurer de la compréhension et la cohérence des demandes.
## L’utilisation de l’IA
C’est le sujet du moment, que je pourrai même définir comme détecteur de mauvais développeur tant celle-ci permet de voir la capacité d’un développeur à vouloir s’assurer de la qualité de son développement.
##### Le mauvais développeur
Il écrit son prompt “fais ça” avec plein d’informations sensibles dans son prompt, il copie le contenu du bloc de code généré, le colle dans son IDE et croise les doigts pour que ça fonctionne. Si c'est le cas, il fait confiance au code et l’oublie dans un coin.
##### Le bon développeur
Il utilise cet outil comme un assistant plutôt qu’un remplaçant en faisant attention de ne pas lui fournir des informations clients ou des informations sensibles.
Il peut l’utiliser de plusieurs façons différentes, notamment :
- Il fait son code et demande conseil d’amélioration, de simplification ou de détection/correction d’éventuelles erreurs.
- Il fait des demandes précises sur des besoins clairs et définis, il analyse le résultat obtenu pour s’assurer de sa cohérence, et il fait valider que des cas particuliers connus sont gérés.
##### Parallèle
C’est comme suivre un GPS sans réfléchir et se retrouver au fond d’un lac parce qu’il disait de tourner à gauche.
##### Conseils
Il faut comprendre ce que propose l’IA, le questionner sur sa réflexion pour pouvoir le challenger, il doit être un outil d’accompagnement permettant de proposer des solutions et se servir de celà pour définir ses propres solutions.
Voici pour cette liste non exhaustive des différences entre un bon et un mauvais développeur, qui j’espère, de par des parallèles un peu absurdes, aura permis d’expliciter l’importance des soft skills. Un bon développeur, ce n’est pas seulement quelqu’un qui écrit du code propre. C’est aussi et surtout quelqu’un qui sait **communiquer**, **écouter**, **travailler en équipe, donner et recevoir du feedback**.
Pour aller plus loin, vous pouvez consulter [cet article qui rappelle les bonnes pratiques sur les erreurs standards faites en Java](/fr/blog/articles/java-pour-les-debutants-parfois-pour-les-experts-aussi).
---
### Java pour les débutants : parfois pour les experts aussi !
URL: https://www.bearstudio.fr/fr/blog/articles/java-pour-les-debutants-parfois-pour-les-experts-aussi
Date: 2025-05-28
Comme vous le savez, Java est un langage qui est utilisé par plusieurs frameworks. Pour un débutant comme moi 😉, il y a beaucoup d’astuces que même les experts oublient parfois, alors qu’elles sont basiques.
Il y a des erreurs qui rendent fou alors qu’en réalité, ce sont des notions de base.
## Le fameux NullPointerException
Cette erreur m’arrive encore tous les jours ! En réalité, elle se produit lorsque tu essaies d’accéder à une méthode ou à une propriété sur **une variable nulle**.
**Exemple :**
```java
String exemple = null;
System.out.println(exemple.length());
// Il va y avoir un null pointer
// La solution est de vérifier la nullité en amont
if (exemple != null) {
System.out.println(exemple.length());
}
```
Un autre piège courant avec les énumérations. Imagine que tu as un type enum et une classe comme ceci :
```java
enum Status {
PENDING,
APPROVED
}
public class MyClass {
Status status;
public Status getStatus() {
return status;
}
}
MyClass a = new MyClass();
```
Si tu veux vérifier le statut et vérifier s’il est PENDING ou non, tu pourrais écrire comme ça :
```java
if (a.getStatus().equals(Status.PENDING)) { }
```
Ce code ne s’exécutera jamais si getStatus() retourne null et l’application plantera, car si getStatus() retourne null, alors tu essaies d’appler la méthode “.equals()” sur ce null. Ce cas provoque donc une NPE(NullPointerException). Une solution serait :
```java
if (Status.PENDING.equals(a.getStatus())) { }
```
Ici la méthode “equals()” sera toujours appelée sur un objet existant. Dans le cas où le getSatus() est null, le “equals()” retournera tout simplement false.
## La différence entre `==` et `equals()`
Une confusion fréquente en Java concerne la comparaison de valeurs :
```java
String a = new String("Bonjour");
String b = new String("Bonjour");
if (a == b) {
System.out.println("Identiques");
} else {
System.out.println("Différents");
}
// Ce code va afficher Différents
```
Les deux variables contiennent la string “Bonjour” mais le résultat est différent. **Pourquoi ?** Imagine que tu écris “Bonjour” sur deux feuilles différentes ⇒ le contenu est identique, mais ce sont deux feuilles distinctes.
Dans notre exemple :
- a et b sont deux feuilles différentes
- Chaque new String() crée une nouvelle “feuille” en mémoire Lorsque l’on compare avec le “==”, on va vérifier s’il s’agit est exactement de la même feuille (donc si les variables ont le même emplacement mémoire).
Si l’on veut simplement comparer les contenus, il faut faire :
```java
String a = new String("Bonjour");
String b = new String("Bonjour");
if (a.equals(b)) {
System.out.println("Identiques");
} else {
System.out.println("Différents");
}
// Ce code va afficher Identiques
```
Ainsi, l’opérateur `==` compare les adresses mémoire, tandis que la méthode `equals()` compare les objets selon la manière dont cette méthode est définie dans la classe.
**Du coup :**
\- Pour les types primitifs (\``int`\`, \``boolean`\`, \``char`\`, \``long`\`, etc.) ⇒ utilise \``==`\`.
\- Pour les objets (\``String`\`, \``List`\`, etc.) ⇒ utilise \``equals()`\`.
## L’oubli du `break` dans les `switch case`
En Java, quand tu utilises un `switch`, le code continue à s’exécuter dans les `case`suivants si tu n’ajoutes pas `break` à la fin de chaque cas.
Exemple :
```java
int jour = 2;
switch (jour) {
case 1:
System.out.println("Lundi");
case 2:
System.out.println("Mardi"); // S'exécute parce que jour = 2
case 3:
System.out.println("Mercredi"); // S'exécute aussi
case 4:
System.out.println("Jeudi"); // S'exécute aussi
default:
System.out.println("Autre jour"); // S'exécute aussi
}
// à la fin on aura comme resultat : Mardi, Mercredi, Jeudi, Autre jour
```
Pour éviter cela, il faut toujours ajouter les `break`.
```java
int jour = 2;
switch (jour) {
case 1:
System.out.println("Lundi");
break;
case 2:
System.out.println("Mardi"); // S'exécute
break; // Et on sort du switch
case 3:
System.out.println("Mercredi");
break;
case 4:
System.out.println("Jeudi");
break;
default:
System.out.println("Autre jour");
}
// Résultat : Mardi
```
## Passage par valeur et Passage par référence
Une erreur fréquente est de penser que les objets sont toujours passés par référence en Java. En réalité, les **types primitifs** (`int`, `double`, `boolean`, etc.) sont passés **par valeur**.
Exemple :
Quand tu passes un `int`, `double` ou `boolean` à une méthode, c’est équivalent à donner une **photocopie** de ta recette à un ami. Si ton ami modifie sa copie (ajoute du sucre, change la température), ta recette originale reste intacte ⇒ Chacun travaille sur sa propre version
```java
public class Test {
public static void main(String[] args) {
int a = 5; // La recette original contient 5 grammes de sucre
modifierValeur(a);
System.out.println(a); // Toujours 5 grammes de sucre
}
static void modifierValeur(int x) {
x = 10; // L'ami change le grammage du sucre de 5 à 10 grammes
}
}
// A ne pas changer car Java copie seulement la valeur, il reste toujours égal à 5
```
Quant aux **objets** sont passés **par référence... mais de manière indirecte** : c'est la référence qui est copiée, pas l'objet lui-même).
Exemple :
Quand tu passes un objet (comme `String`, `ArrayList`), c'est comme donner un **double de ta clé d'appartement** à un ami. Ton ami ne peut pas changer ta clé, mais peut entrer dans ton appartement et déplacer les meubles ⇒ Vous accédez au même appartement avec des clés différentes.
```java
class Appartement {
String couleurMur;
Appartement(String couleur) { this.couleurMur = couleur; }
}
public class Test {
public static void main(String[] args) {
Appartement monAppart = new Appartement("blanc");
rendreVisite(monAppart);
System.out.println(monAppart.couleurMur); // Le mur a été repeint en bleu
}
static void rendreVisite(Appartement appart) {
appart.couleurMur = "bleu"; // Repeint ton mur
}
}
```
⚠️ Il n'est pas recommandé de modifier un objet par référence, car cela rend le code difficile à lire et à comprendre. On ne sait pas facilement quand et où l'objet peut être modifié.
**En conclusion**, même si ces notions semblent basiques, elles peuvent facilement causer des bugs frustrants, même aux développeurs expérimentés. C’est pourquoi il est essentiel de bien comprendre ces fondamentaux et de toujours garder en tête que même les bases peuvent parfois nous piéger.
Auteur: [Mariem Mkassmi](https://www.linkedin.com/in/mkassmi-meriem-6b1326169/)
---
### Gérer facilement le contenu de votre site avec Outstatic
URL: https://www.bearstudio.fr/fr/blog/articles/gerer-facilement-le-contenu-de-votre-site-avec-outstatic
Date: 2025-04-25
Il y a quelque temps, j’ai travaillé sur une landing page avec une partie blog. Deux contraintes majeures se présentaient :
- Intégrer facilement cette section dans un projet Next.js déjà en place,
- Permettre à n'importe qui d'ajouter des articles, sans écrire une seule ligne de code.
Après plusieurs recherches et tests, j’ai finalement opté pour la librairie [Outstatic](https://outstatic.com/).
## Qu’est-ce que Outstatic ?
Outstatic est un CMS (Content Management System) open source conçu pour les développeurs utilisant Next.js. Mais contrairement aux CMS classiques comme WordPress, il a plusieurs particularités intéressantes :
- **Sans base de données :** Outstatic fonctionne uniquement avec des fichiers Markdown sauvegardés dans votre dépôt GitHub. Pas besoin de gérer une base de données, tout est simple et rapide.
- **Hébergé directement dans le projet :** Outstatic s’intègre directement à votre projet Next.js. Pas de service externe ou de déploiement séparé.
- I**nterface utilisateur intuitive :** Une fois configuré, n'importe qui (même sans connaissances techniques) peut créer des articles ou des pages grâce à une interface d'administration.
## Avantages et inconvénients
Avant de vous présenter concrètement la librairie, je vais vous donner, selon moi, quelques avantages et inconvénients de cette librairie par rapport aux autres CMS plus classiques.
### Avantages
- Simplicité et rapidité : En quelques minutes, vous obtenez un blog fonctionnel.
- Auto-hébergé : Tout reste dans votre projet, aucune dépendance externe.
- Gestion de brouillons : Flexible pour publier vos articles au bon moment.
- Aucune base de données : Parfait pour les projets statiques.
### Inconvénients
- Dépendance à GitHub : Outstatic nécessite une connexion via GitHub, donc chaque contributeur doit avoir un compte et être ajouté à l'organisation. Il n’est pas possible d’utiliser Outstatic avec d’autres solutions de versioning. De plus, cela peut poser problème dans certaines entreprises pour des profils non techniques.
- Collaborations complexes : Si vous travaillez avec une organisation, cela nécessite une configuration OAuth
- Ne convient pas pour les gros volumes de données : Lorsque les fichiers des articles, stockés dans votre dépôt Git, deviennent trop nombreux, cela peut entraîner une diminution des performances de votre site.
## Comment configurer Outstatic ?
Configurer Outstatic sur votre projet est très simple, il suffit de seulement 3 étapes :
### Étape 1 : Installer Outstatic
Ajoutez Outstatic à votre projet en exécutant :
```bash
npm install outstatic
```
### Étape 2 : Créer une application OAuth sur GitHub
Outstatic utilise GitHub pour l'authentification et la gestion des articles. Voici comment créer une application OAuth :
1. Rendez-vous sur [GitHub Developer Settings](https://github.com/settings/developers).
2. Cliquez sur New OAuth App.
3. Remplissez les champs :
- Application name
- Homepage URL : L'URL de votre site (par exemple, `http://localhost:3000` en local).
- Authorization callback URL : Ajoutez `/api/auth/callback/github` à votre URL (par exemple, `http://localhost:3000/api/auth/callback/github`).
4. Une fois l'application créée, notez vos client ID et client secret.

### Étape 3 : Intégrer Outstatic dans votre projet :
1. Créer un fichier .env avec les variables récupérées précédemment.
```bash
OST_GITHUB_ID=YOUR_GITHUB_OAUTH_APP_ID
OST_GITHUB_SECRET=YOUR_GITHUB_OAUTH_APP_SECRET
# OST_REPO_SLUG
# The name of your repository on GitHub without the username
OST_REPO_SLUG=YOUR_GITHUB_REPOSITORY_SLUG
# OPTIONAL
# If empty this will default to your GitHub username
OST_REPO_OWNER=YOUR_GITHUB_USERNAME
# OPTIONAL
# If empty this will default to main
OST_REPO_BRANCH=YOUR_GITHUB_REPOSITORY_BRANCH
```
2. En suivant la [documentation officielle d’Outstatic](https://outstatic.com/docs/getting-started#adding-outstatic-to-a-nextjs-website), il vous sera très facile de configurer les éléments restants : layout, page administrateur et api
## Comment ajouter du contenu ?
### Création de la collection
Depuis l'interface, vous pouvez créer une collection : par exemple pour un blog vous allez créer la collection “Articles” qui contiendra tous vos articles. Par défaut, chaque élément de la collection a un titre, une description, une image, un auteur, etc, mais vous pouvez également créer des champs personnalisés. Une fois l’article créé, il est sauvegardé dans votre dépôt GitHub sous forme de fichier Markdown dans le dossier défini (content par défaut).

### Visualisation et récupération des articles :
Pour récupérer vos articles Markdown, utilisez les méthodes fournies par Outstatic : `getDocuments` ou `getDocumentBySlug`. Convertissez ensuite le contenu en HTML pour les styliser ensuite.
```javascript
const posts = getDocuments('articles', ['title', 'slug']);
const post = getDocumentBySlug('articles', slug, [
'title',
'publishedAt',
'slug',
'author',
'content',
'coverImage',
]);
```
## Comment styliser l’article ?
Dans mon cas, j’ai choisi d’utiliser Tailwind CSS et plus particulièrement [Tailwind typography](https://github.com/tailwindlabs/tailwindcss-typography) pour gérer le style des articles Markdown : vous pouvez personnaliser vos articles comme vous le souhaitez, en modifiant le style des titres, des images etc…
```jsx
{data.title}
Publié le {data.date} par {data.author}
{content}
```
## Article en écriture avec Outstatic VS le résultat sur le site
Lorsque vous écrivez un article sur l’interface administrateur, le style n’est pas le même que celui de la page ou vous allez afficher l’article pour vos utilisateurs. Voici par exemple l’interface d’Outstatic sur la première image, c’est ici que vous écrivez l’article, remplissez son titre, sa description etc… Sur la deuxième image, j’ai ajouté du style, et utilisé les propriétés “title”, “author” et “cover image” pour créer l'en-tête de l’article.


## Mon avis sur Outstatic
Dans le passé, j’ai eu l’occasion d’utiliser WordPress pour plusieurs projets, que ce soit dans un cadre professionnel, personnel ou scolaire. Si cet outil reste une référence pour la création de sites et de blogs, il impose néanmoins certaines contraintes en matière de personnalisation. En général, on choisit un thème prédéfini pour structurer l’affichage des articles, ce qui limite la flexibilité et l’intégration au sein d’un projet plus complexe.
Avec Outstatic, l’approche est bien différente. Cet outil offre une gestion de contenu entièrement personnalisable, permettant non seulement de structurer les articles selon ses propres besoins, mais aussi de l’intégrer directement dans un site déjà existant. Il devient ainsi possible de profiter d’une solution de gestion de contenu légère et modulable, sans avoir à dépendre d’un écosystème lourd comme celui de WordPress.
En conclusion, [Outstatic](https://outstatic.com/) est une solution simple et efficace pour ajouter une section blog à un site Next.js. C'est un outil parfait pour les projets où la gestion du contenu doit être rapide et accessible, sans sacrifier le contrôle sur le code.
Auteur: [Jeanne Grenet](https://www.linkedin.com/in/jeanne-grenet)
---
### Le canard en plastique est votre ami !
URL: https://www.bearstudio.fr/fr/blog/articles/le-canard-en-plastique-est-votre-ami
Date: 2025-03-27
Le titre peut sembler bizarre, mais c’est le nom d’une méthode que beaucoup utilisent au quotidien sans vraiment le réaliser.
Prenons l’exemple suivant : Vous cherchez vos clés, après qu’elles aient encore disparu mystérieusement au moment de partir.
Beaucoup retracent leur chemin de long en large et en travers sans succès. Après un moment, vous demandez de l’aide, et d’un coup, vous vous souvenez exactement où vos clés vous attendent
Si cette situation vous parle, vous avez utilisé la méthode du canard en plastique. Mais pourquoi ce nom ?
Tout viendrait d'une anecdote publiée dans le livre _The Pragmatic Programmer_, écrit par Andrew Hunt et David Thomas, dans lequel un développeur garderait un canard en plastique sur son bureau, et se mettrait à lui parler quand il rencontre un problème avec son code, d'où le nom.
Paru en 1999, ce livre est rapidement devenu une référence pour les nombreuses méthodes et astuces qu’il présente pour améliorer son processus de développement. Une réédition, bien que seulement en anglais est sortie en 2019, avec des mises à jour pour refléter les changements dans le domaine.
Petit fun fact, mais ces 2 développeurs ont aussi participé à l’écriture du manifeste Agile.
## C’est quoi cette méthode ?
Le principe est très simple : Quand on est bloqué, et qu’on pense avoir tout essayé, on explique le problème à notre canard. Non, inutile d’aller en animalerie, nous parlons ici du canard en plastique que vous avez probablement dans votre salle de bain. Avec son aide, on va repasser sur notre code, en expliquant ce qu’il doit faire, ce qu’il fait, et dans quel but. Le souci se révélera de lui-même quand notre explication et le code ne s'alignent pas ! Pour simplifier, on est forcé de prendre du recul sur le code écrit.
Bien que le principe soit simple, il est plus difficile de l’appliquer. Notre cerveau, dans le but d’économiser de l’énergie et des maux de tête, va survoler des parties de notre raisonnement. Cette petite optimisation pour gagner du temps sur la réflexion va nous en faire perdre PLUS car notre erreur se cache dans ce qu’on survole.
Le canard est donc là pour nous servir d’ancre. Lui, il ne connaît pas le contexte du projet, et on doit donc se forcer à tout reprendre de zéro.
De plus, après être confronté à un ou plusieurs échecs, nous avons tendance à entrer dans une spirale défaitiste. La prise de recul permet de se “réinitialiser”,
## Démonstration
Assez parlé de la théorie, passons à la pratique avec l’exemple suivant :
J'ai une liste de nombres avec lesquels je ne veux additionner que les nombres pairs.
```javascript
const array = [1, 2, 4, 7, 14, 21, 34, 39];
```
J’ai donc écrit la fonction suivante
```javascript
const reduceEvenNumbers = (numberArray: Array) => {
return numberArray.reduce((sum, num) => {
return num % 2 === 1 ? sum + num : sum;
}, 0)
}
```
En lançant cette fonction avec l’array donné, je devrais recevoir 54, mais j'obtiens 68.
La situation est idéale pour utiliser la méthode du canard en plastique !
J’explique donc à mon canard ce que je veux faire:
> _“Voilà Jean-Luc, je dois additionner tous les nombres pairs présents dans cette liste. Pour ça, j’ai créé une fonction qui applique un reduce sur ma liste._
>
> _Un reduce est un accumulateur qui parcourt un array et le réduit à une valeur selon la fonction donnée. J’ai donc en entrée une fonction personnalisée, et la valeur d’initialisation, qui est bien à 0._
>
> _Ma fonction personnalisée permet d’ajouter à mon accumulateur la valeur parcourue seulement si le nombre est pair._
>
> _Pour vérifier si l’élément parcouru est pair, j’applique un modulo, et s’il me reste 0, alors j’ai un nombre impair.”_
Et c’est en expliquant le raisonnement que l’on peut voir l’erreur. La vérification sur mon modulo n’est pas la bonne, et doit être changée pour enfin avoir le résultat attendu
```javascript
const reduceEvenNumbers = (numberArray: Array) => {
return numberArray.reduce((sum, num) => {
return num % 2 === 0 ? sum + num : sum;
}, 0)
}
```
Bien sûr, on n’oublie pas de remercier notre canard, en fin de session.
> _Merci Jean-Luc !_
## Sans canard en plastique, ça marche ?
L’avantage du canard en plastique, c’est qu’il n’est jamais très loin, mais dans les rares cas où il est absent, comment faire pour s’en sortir ?
Petit rappel, mais le canard en plastique est un objet, et n’importe quel autre objet (à condition de pouvoir le personnifier) peut le remplacer.
Il est même possible, au lieu de prendre un objet, de demander à un collègue, un membre de la famille, ou n’importe qui (selon votre niveau d’anxiété sociale et possible NDA) à participer !
Cette demande pourra même se transformer en session de [Peer Programming](/fr/blog/articles/peer-programming).
## Petites astuces supplémentaires
Parfois, même avec cette méthode, le problème nous échappe. Dans ce cas, il existe des petites astuces supplémentaires.
### Les logs
C’est généralement le premier réflexe en tant que développeur, mais ajouter des logs au code est une façon simple de voir où se situe le problème.
### Why ?
Comme un enfant de 5 ans, le but est de se demander “Pourquoi ?” à chaque problème que l’on rencontre. Si on reprend le même exemple, voilà à quoi ça pourrait ressembler :
> - _Pourquoi j’ai le mauvais résultat ? Parce que je n’additionne pas les nombre pairs._
> - _Pourquoi je n’additionne pas les nombres pairs ? Parce que ma condition ne marche pas comme prévu._
> - _Pourquoi ma condition ne marche pas comme prévu ? Parce que je regarde si les nombres sont impair plutôt que pair._
En remontant assez haut, on peut trouver une ressource externe qui ne se comporte pas comme prévu (une API, une librairie, un problème de versioning, etc… ), ou localiser le problème entre le clavier et la chaise.
Attention quand même à ne pas remonter trop loin avec ce raisonnement, c’est une façon facile de se perdre dans une boucle infinie de “Pourquoi”.
### Explain it like I’m Five
Cette fois-ci, au lieu de se comporter comme un enfant, on va expliquer notre code de façon simplifiée. En soit, c'est une méthode pour expliquer suffisamment en détail le code à débugger
> _Alors voilà ! J’ai une liste de nombres. Certains sont pairs, d’autres impairs. Je veux les additionner, mais mon programme n’arrive pas à comprendre lesquels sont pairs. Pour savoir si un nombre est pair, je fais ça => X % 2. Je divise par 2, et s’il me reste 0, alors j’ai un chiffre pair, et s’il reste 1, alors c’est impair. Peut-être que j’ai mal vérifié…_
### Chemin inversé
Avec cette méthode, au lieu de repartir du début du code, jusqu’à trouver le problème, on part du problème, et on retrace le chemin, pour trouver l’incohérence entre ce qu’on veut et ce qui est fait.
> _Si la somme finale n’est pas la bonne, c’est que je n’additionne pas les bons nombres, Je vais regarder comment la somme est calculée. J’additionne un nombre que s’il est impair d’après le code. Mais c’est l’inverse dont j’ai besoin. J’inverse la condition, et ça devrait marcher !_
J’espère que cet article vous sera utile, et que votre premier réflexe au prochain problème sera de trouver votre canard ! Et si votre canard n'est pas suffisant, prenez en otage un collègue pour une session de [Peer Programming](/fr/blog/articles/peer-programming)
---
### Les bases du design pour les dev front
URL: https://www.bearstudio.fr/fr/blog/articles/les-bases-du-design-pour-dev-front
Date: 2025-02-27
Le design ne se résume pas à l'esthétique. Il joue un rôle crucial dans la manière dont les utilisateurs perçoivent et interagissent avec un produit ou un service, et cette [expérience utilisateur (UX) est primordiale](/fr/blog/articles/pourquoi-lexperience-utilisateur-est-elle-importante). En effet, un bon design facilite la compréhension et l'utilisation afin de créer une expérience positive. À l'inverse, un mauvais design peut entraîner de la confusion et pousser les utilisateurs à délaisser votre produit. Le design est par conséquent un facteur clé de succès pour toute application.
C'est pourquoi posséder des notions de design est un véritable atout pour un dev front. En effet ces connaissances peuvent permettre d’avancer sur des features sans maquettes tout en gardant un design réfléchi ou encore de faciliter la communication avec les designers pour arriver au meilleur résultat possible. Pas besoin de devenir un expert en design pour ça : l'objectif est d'acquérir des bases applicables facilement, pas de savoir faire un design system de A à Z.
## Les bases du design pour les dev front : Que faut-il savoir ?
Commencez par des concepts simples mais indispensables comme les théories/lois de la Gestalt appliquées au design. La Gestalt est une théorie psychologique née en Allemagne au début du XXe siècle, cherchant à expliquer notre façon de percevoir ce qui nous entoure. De ces lois ont découlé des notions de design, qui permettent rapidement d’améliorer des interfaces et de détecter des mauvaises pratiques.
### Loi de proximité
Les éléments proches les uns des autres sont perçus comme appartenant à un même groupe. Si des éléments sont trop proches ou, au contraire, trop éloignés, on risque de mal associer les informations entre elles.

Exemple à gauche ici, si tout est espacé de la même façon, sauriez vous me dire si le prix est au dessus, ou en dessous de l’item qu’il concerne ? Avec les bons espacements, on voit que l’exemple de droite devient beaucoup plus clair.
Je vous invite à lire [cet article qui en parle plus en détails](/fr/blog/articles/la-loi-de-proximite) si le sujet vous intéresse
### Loi de similarité
Les éléments qui se ressemblent (forme, couleur, taille) sont vus comme appartenant à un même ensemble.

Ici, dans un formulaire avec des cases à cocher, si elles ne sont pas visuellement identiques, on ne les associera pas instinctivement, même si elles appartiennent au même champ.
Ces deux lois sont essentielles pour poser les bases, mais d’autres principes de la Gestalt peuvent enrichir votre compréhension si cela vous intéresse. En parallèle, voici d’autres notions fondamentales :
### Le feedback
Chaque action doit produire une réaction visible, compréhensible et immédiate. Que ce soit un toast indiquant le succès d’une action ( création, sauvegarde …), un loader pour montrer que c’est en cours de chargement ou encore l’invalidation d’un champ de formulaire, un bon feedback est essentiel à une bonne expérience utilisateur.

### L’affordance
Un design doit être compréhensible : chaque élément doit indiquer clairement son utilité. Par exemple, un bouton doit ressembler à un bouton.

### Apprentissage externe
Les utilisateurs ont des attentes basées sur leurs expériences passées. Une barre avec une icône de loupe, c’est une barre de recherche. Il est préférable de respecter ces conventions pour ne pas désorienter les utilisateurs.
Je ne dis pas qu’on ne peut pas innover, mais quand on n’est pas designer, autant rester dans les habitudes des utilisateurs.

### Apprentissage interne
De la même manière, un utilisateur va apprendre à utiliser l’application qu’on lui met entre les mains. Il faut donc rester cohérent au sein du projet. Si le bouton “valider” est à droite et “annuler” à gauche dans une modale, ils ne doivent pas être inversés dans une autre.
### Hiérarchie visuelle
Tout ne doit pas être au même niveau ou à la même taille. L’information importante peut être mise en valeur avec une police plus grande, un gras plus prononcé, ou une couleur marquante. Si on ne veut pas diminuer la taille d’un élément pour pas qu’il ne devienne trop petit, utiliser une couleur plus claire par exemple peut permettre d’obtenir le même effet. Attention cependant à garder une cohérence visuelle entre les éléments de même type et de même importance.

En intégrant ces principes, il sera plus simple en tant que dev front de comprendre les choix faits par les designers, et encore mieux, pouvoir nous-même ajouter des fonctionnalités sans passer par l’étape designer (ou seulement pour qu’il valide), si celui-ci n’est pas disponible ou qu’il n’y en a pas pour le projet.
### Faire des maquettes
Pour aller plus loin, vous pouvez vous pencher sur la réalisation de maquettes/ modifications de maquettes existantes. Pourquoi ? Imaginons qu’on vous demande une feature complexe sans maquette : il sera plus simple et rapide d'expérimenter et de faire valider son design sur un outil comme figma, plutôt que directement dans le code.
Figma, en particulier, est un outil puissant et accessible. Avec lui, vous pouvez créer des composants réutilisables et garder une cohérence dans vos designs. Pour bien débuter, de nombreux tutoriels sont disponibles, et la [documentation officielle](https://help.figma.com/hc/fr/sections/23536356509975-Cr%C3%A9er-des-syst%C3%A8mes-de-design) est un excellent point de départ. Vous pouvez également trouver des starter pour figma, avec des composants déjà disponibles, comme c’est le cas de notre starter [Start UI Figma](https://www.figma.com/community/file/1025698982013308087). Je vous invite à checker ça, ne serait-ce que pour apprendre et expérimenter sans avoir à partir de zéro.
### Conclusion
Apprendre le design n’est pas une question de changer de carrière, mais plutôt d’élargir votre champ de compétences. En tant que dev front, maîtriser quelques bases de design vous permettra d’être plus autonome, de proposer des solutions adaptées et de collaborer efficacement avec les designers.
---
### Difference entre Class et Record en Java
URL: https://www.bearstudio.fr/fr/blog/articles/difference-entre-class-et-record-en-java
Date: 2025-01-20
## Différence entre une classe et un record en Java
Depuis la version 16 de Java, un nouveau type de structure de données appelé **record** a été introduit. Il s'agit d'une simplification du modèle classique de classe, spécialement conçu pour les **objets immuables** et les **conteneurs de données**. Comparons en détail les **classes** et les **records** en Java, leurs différences et leurs usages.
### 1\. Qu'est-ce qu'une classe en Java ?
Une **classe** en Java est une structure qui permet de définir des objets avec des **états** (via des champs ou variables d'instance) et des **comportements** (via des méthodes). Une classe est très flexible et peut inclure des méthodes, des constructeurs, des blocs d'initialisation statiques, ainsi que des champs privés, publics, ou protégés.
### Exemple d'une classe simple :
```java
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
@Override
public String toString() {
return "Person{name='" + name + "', age=" + age + "}";
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
return age == person.age && name.equals(person.name);
}
@Override
public int hashCode() {
return Objects.hash(name, age);
}
}
```
### Caractéristiques des **classes** :
- **Mutable** : Les classes peuvent contenir des **champs modifiables** (on peut changer les valeurs des attributs après l'instanciation).
- **Code répétitif** : Pour de simples classes contenant des données, nous devons souvent définir manuellement des méthodes comme `toString()`, `equals()`, et `hashCode()`, ce qui entraîne beaucoup de code répétitif (boilerplate).
- **Personnalisation** : Les classes permettent une grande personnalisation avec des constructeurs variés, des méthodes complexes, et des fonctionnalités comme l'héritage.
- **Héritage** : Les classes peuvent **hériter** d'autres classes et implémenter des interfaces, ce qui offre une grande flexibilité pour réutiliser et étendre du code.
### 2\. Qu'est-ce qu'un record en Java ?
Un **record** est une structure de données simplifiée introduite dans Java 16, destinée à **remplacer les classes de type DTO (Data Transfer Object)**, qui sont souvent utilisées pour encapsuler des données sans comportement complexe. Les records sont conçus pour être **immuables**, et le compilateur génère automatiquement pour eux les méthodes `toString()`, `equals()`, et `hashCode()`.
### Exemple d'un record simple :
```java
public record Person(String name, int age) {
// Le constructeur, les getters, toString, equals, et hashCode sont générés automatiquement
}
```
### Caractéristiques des **records** :
- **Immuable** : Par défaut, les champs d'un record sont **final** et ne peuvent pas être modifiés une fois initialisés.
- **Concise** : Un record est beaucoup plus concis qu'une classe. Le compilateur génère automatiquement des méthodes comme `toString()`, `equals()`, `hashCode()`, ainsi que des **constructeurs canoniques** pour initialiser les champs.
- **Pas d'héritage** : Les records **ne peuvent pas étendre** d'autres classes, mais ils peuvent **implémenter des interfaces**. Cela limite leur usage à des **conteneurs de données simples**.
- **Optimisé pour les données** : Les records sont spécialement conçus pour des cas où l'objectif est de contenir et de transporter des données sans comportement complexe.
### 3\. Comparaison entre une classe et un record
| **Caractéristique** | **Classe** | **Record** |
| -------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Mutabilité** | Les classes peuvent être mutables ou immuables. | Les records sont **immutables** par défaut, les champs sont `final`. |
| **Code répétitif (boilerplate)** | Nécessite des méthodes manuelles (`toString`, `equals`, etc.). | Génère automatiquement `toString()`, `equals()`, `hashCode()`, et un constructeur canonique. |
| **Constructeurs** | Peut avoir plusieurs constructeurs avec différentes signatures. | Dispose d'un **constructeur canonique** généré automatiquement pour tous les champs. |
| **Héritage** | Peut hériter d'autres classes et implémenter des interfaces. | **Ne peut pas hériter** d'une autre classe, mais peut implémenter des interfaces. |
| **Utilisation** | Convient pour des objets complexes avec des comportements variés. | Convient aux **modèles de données simples** ou aux **DTO** immuables. |
| **Personnalisation** | Permet de personnaliser le comportement (logique, mutabilité, etc.). | Limité à la gestion des données, moins de flexibilité pour ajouter des méthodes ou de la logique. |
### 4\. Quand utiliser une classe ?
Les **classes** sont appropriées lorsque :
- Tu as besoin d'**objets mutables** dont l'état peut changer après la création.
- Tu dois encapsuler à la fois des **données et des comportements** (méthodes), ou lorsque ton objet doit inclure une logique métier.
- Tu dois implémenter l'**héritage** (une classe qui hérite d'une autre).
- Tu as besoin d'une grande flexibilité avec des constructeurs variés, des blocs d'initialisation, ou des méthodes supplémentaires.
### Exemple d'utilisation d'une classe :
Si tu dois créer une classe représentant un **compte bancaire** qui permet de modifier son solde et d'exécuter des opérations :
```java
public class BankAccount {
private String accountHolder;
private double balance;
public BankAccount(String accountHolder, double balance) {
this.accountHolder = accountHolder;
this.balance = balance;
}
public void deposit(double amount) {
balance += amount;
}
public void withdraw(double amount) {
if (amount > balance) {
throw new IllegalArgumentException("Insufficient balance");
}
balance -= amount;
}
@Override
public String toString() {
return "BankAccount{accountHolder='" + accountHolder + "', balance=" + balance + "}";
}
}
```
### 5\. Quand utiliser un record ?
Les **records** sont particulièrement utiles lorsque :
- Tu veux un objet qui sert uniquement à **stocker des données** de manière **immuable**.
- Tu veux **réduire le code répétitif** : pas besoin de réécrire `equals()`, `hashCode()`, ou `toString()`.
- Ton objet n'a pas besoin d'hériter d'une autre classe, mais peut implémenter des interfaces.
- Tu développes des **Data Transfer Objects (DTO)**, des objets simples utilisés pour transférer des données entre différentes couches ou systèmes.
### Exemple d'utilisation d'un record :
Imaginons que tu dois stocker les informations d'un **utilisateur** sans logique métier spécifique :
```java
public record User(String username, String email) {
// Constructeur, getters, equals, hashCode et toString sont générés automatiquement
}
```
Tu peux facilement créer des instances comme ceci :
```java
User user = new User("john_doe", "john@example.com");
System.out.println(user.username()); // john_doe
```
### 6\. Exemple combiné : Classe et Record
Parfois, tu peux combiner des **classes** et des **records** dans un même projet pour différents types de besoins. Par exemple, un **compte bancaire** pourrait être une classe, tandis qu'un **rapport financier** ou un **historique de transaction** pourrait être un record.
### Exemple combiné :
```java
public class BankAccount {
private String accountHolder;
private double balance;
public BankAccount(String accountHolder, double balance) {
this.accountHolder = accountHolder;
this.balance = balance;
}
public void deposit(double amount) {
balance += amount;
}
public void withdraw(double amount) {
if (amount > balance) {
throw new IllegalArgumentException("Insufficient balance");
}
balance -= amount;
}
public TransactionRecord createTransactionRecord(double amount, String type) {
return new TransactionRecord(amount, type, LocalDate.now());
}
}
public record TransactionRecord(double amount, String type, LocalDate date) {
}
```
### 7\. Conclusion
En résumé, les **classes** en Java sont très flexibles et polyvalentes, permettant de définir à la fois des données et des comportements, tandis que les **records** se concentrent sur la simplification de la gestion des données immuables. Utiliser des **records** réduit le code répétitif et rend la gestion des données plus concise, mais si tu as besoin de mutabilité ou d'héritage, une **classe** sera plus appropriée.
---
### Pourquoi l'expérience utilisateur est-elle importante ?
URL: https://www.bearstudio.fr/fr/blog/articles/pourquoi-lexperience-utilisateur-est-elle-importante
Date: 2024-03-27
## Comprendre le contexte
Dans le monde numérique d'aujourd'hui, le succès d'une application mobile/web dépend non seulement de son apparence, de ses fonctionnalités, mais aussi de la **qualité de l'expérience utilisateur**. Une expérience utilisateur fluide et intuitive est décisive pour **attirer** les utilisateurs, les **fidéliser** et en fin de compte, assurer un **succès commercial**.
## Clarifions les enjeux
Contrairement à la conception graphique, la conception de l'UX design **ne** **peut pas** être une réflexion après coup, ou une couche esthétique ajoutée une fois le projet terminé. Un projet réussi va au-delà de ses fonctionnalités - **il nécessite des [user flow (flux utilisateurs)](/fr/blog/articles/parcours-utilisateur-ux) bien pensés** dès le départ.

## "La forme suit la fonction" - Comment appliquer cela de nos jours au design d’interface ?
Il est aujourd’hui acté qu'un **design** devrait être principalement **pensé** par rapport à son **objectif ou sa fonction prévue.** Ce principe a démontré son efficacité depuis le XIXe siècle. L'architecte [Louis Sullivan](https://fr.wikipedia.org/wiki/Louis_Sullivan), une figure influente de l'architecture moderne, a énoncé l'une des phrases les plus emblématiques de l'histoire du design : **« La forme suit la fonction »**.
Dans le contexte de la conception UX (Expérience Utilisateur) pour les applications, ce principe souligne que la conception de **l'interface utilisateur** (forme) doit être guidée par les **tâches et la fonctionnalité** prévues par l'application (fonction).
On peut résumer en disant que les **principes** de la conception UX soulignent l'importance **d'aligner design et fonctionnalité** pour créer une expérience utilisateur optimale.
##### Une conception centrée sur l’utilisateur
Le design de l'application doit être **intuitif** et **user-friendly**. Cela garantit que les utilisateurs peuvent comprendre et interagir facilement avec l'interface pour **accomplir leurs tâches** de manière efficace.

##### L’alignement des tâches
Les éléments de design (**boutons**, **menus**, **navigation**...) doivent être alignés sur les **tâches** et les **objectifs** des utilisateurs. Ils doivent être organisés et présentés de manière à suivre le **flux ou parcours** naturel de l'utilisateur afin d'aider à atteindre leurs objectifs **sans complexité inutile.**

##### La clarté et la simplicité
Le design visuel ne devrait **pas** prendre le pas sur la fonctionnalité. Garder un design simple et clair aide les utilisateurs à **se concentrer** sur les éléments essentiels et les actions nécessaires pour **accomplir leurs tâches**. Une ornementation ou complexité inutiles peuvent **entraver** l'expérience utilisateur.

##### La cohérence
La cohérence dans les éléments de design et les patterns présents à travers l'application améliore la compréhension des utilisateurs et **réduit la charge cognitive.** Ainsi, les utilisateurs devraient être en mesure de prévoir le comportement de certaines fonctionnalités ou interactions en se basant sur leurs **expériences antérieures** au sein de l'application.

##### Un design responsive
Le design devrait **s'adapter** à différents appareils et tailles d'écran sans compromettre les fonctionnalités. Un **design responsive** garantit que les utilisateurs puissent interagir avec l'application quel que soit le dispositif qu'ils utilisent.

##### L’accessibilité
Le design devrait prendre en compte les **principes d'accessibilité**, et ce, afin de garantir que tous les utilisateurs, y compris ceux ayant des handicaps, puissent utiliser l'application de manière efficace. Cela confirme l'aspect fonctionnel de rendre l'application utilisable à un **public diversifié**.

## “Pourquoi cela m'intéresserait en tant qu'entrepreneur ?”
Eh bien, cela peut se résumer par "utilisateur satisfait = **entreprise prospère".** Mais creusons un peu plus le sujet.

Voici quelques raisons clé pour lesquelles un mauvais design UX ou l'absence de design UX peuvent avoir une influence négative sur une entreprise :
##### Satisfaction client à la baisse
Les utilisateurs s'attendent à ce que les sites web, les applications ou les produits utilisés soient intuitifs, faciles à naviguer et réactifs. Une mauvaise UX entraîne donc de la **frustration** et du **mécontentement de la part des utilisateurs.**
##### Taux de rebond élevé
Les utilisateurs qui ont **du mal à navigue**r, à comprendre un site web ou une application sont plus susceptibles de **partir** sans accomplir leurs actions prévues. Cela entraîne des **taux de rebond** plus élevés, impactant les taux de conversion et les revenus.
##### Faible fidélisation client
Les utilisateurs ayant une expérience négative sont **moins susceptibles de revenir** sur un site web. Une mauvaise UX peut **réduire** la fidélité client.
##### Mauvaise réputation
Les utilisateurs mécontents sont plus enclins à **partager leurs mauvaises expériences**, que ce soit de bouche à oreille ou par le biais d'avis en ligne ce qui peut conduire, à terme, à une **mauvaise réputation**.
##### Impact sur les taux de conversions
Une interface utilisateur **confuse ou compliquée** peut entraver l'entonnoir de conversion. Les utilisateurs peuvent **abandonner** des paniers d'achat, ne pas remplir de formulaires ou éviter de faire des transactions en ligne, ce qui **affecte** les résultats financiers de l'entreprise.
##### Désavantage concurrentiel
Dans le **marché concurrentiel** d'aujourd'hui, les utilisateurs ont l'embarras du choix. Une mauvaise UX peut conduire les utilisateurs à aller chez les concurrents, qui offrent une expérience plus fluide et user-friendly.
##### Augmentation des coûts de support client
Les utilisateurs rencontrant des difficultés sont plus susceptibles de solliciter le support client, **augmentant la charge de travail** pour l'équipe de support. Cela peut entraîner des **coûts de support plus élevés**.
##### Perte de confiance
Une expérience utilisateur frustrante ou déroutante peut **entacher la confiance en une marque**. Les utilisateurs peuvent remettre en question la fiabilité et la crédibilité d'une entreprise s'ils rencontrent **des difficultés** dans l'utilisation de ses produits ou services.
##### Préoccupations en matière d’accessibilité
Ignorer les principes d'accessibilité peut **exclure une partie de la population** ayant des handicaps. Cela limite non seulement la base de clients potentiels, mais peut également entraîner des **problèmes juridiques** dans certaines juridictions. Notamment en France, où la conformité en matière d'accessibilité est requise.
## Conclusion
Tout comme les ingénieurs civils veillent à ce qu'un bâtiment puisse résister à la gravité, les architectes adaptent la maison pour répondre aux besoins du propriétaire. De manière similaire, dans notre scénario actuel, tandis que les **développeurs** offrent un **support** **technique** et veillent à ce que l'application **fonctionne** **sans** **faille**, les **concepteurs** **UX** jouent le rôle **d'architectes** **des** **applications**. Leur rôle est de s'assurer que l**es utilisateurs interagissent facilement avec l'application et atteignent leurs objectifs sans effort.**
Si vous souhaitez créer un produit adapté aux **besoins** et aux **demandes** de vos utilisateurs, BearStudio propose des [services d’UX Design](/fr/prestations/ux-design) pour **améliorer l'expérience utilisateur** de votre produit.
**Négliger l'UX** peut sembler économique, mais cela entraîne des **dépenses supplémentaires à long terme**. Corriger ultérieurement l'une des problématiques mentionnées ci-dessus nécessite un **développement supplémentaire, du temps et des ressources**. Cela a pour conséquence d’augmenter les coûts de manière significative. **Investir dans une bonne expérience utilisateur** dès le départ **permet d'économiser de l'argent** en évitant ces dépenses futures.
Pour avoir une perception **mature** d'un produit, il doit être compris comme un **organisme systémique** qui, pour fonctionner au mieux, ne peut manquer d'aucun composant, parmi lesquels le design UX.
Toutefois, si votre produit est déjà développé et **manque de logique** UX, nous proposons un [audit UX](/fr/prestations/ux-design) de votre projet. Vous pourrez ainsi connaître ses **points faibles** ainsi que nos recommandations d’action pour **l’optimiser** !

---
### Les Ours au Camping des Speakers 2023
URL: https://www.bearstudio.fr/fr/blog/articles/les-ours-au-camping-des-speakers-2023
Date: 2023-11-24
Les 15 et 16 juin derniers, l'équipe du BearStudio a eu l'occasion de participer à une expérience unique : le [Camping des Speakers](https://camping-speakers.fr/). Dans cet article, nous partageons notre expérience et les moments marquants de ces deux jours de conférences techs dans un camping en Bretagne.
## Le Camping des Speakers : Une conférence tech atypique
Le Camping des Speakers est une conférence qui se déroule, comme son nom l’indique, dans un camping, en Bretagne. Au-delà de sa localisation, elle se démarque aussi par son ambiance bon enfant poussée par les organisateurs. En effet, bien qu’on puisse y suivre des talks « classiques », on y retrouve aussi des talks plus originaux qui prennent place partout dans le camping ! On a notamment pu jouer au Möbkky, une variante « mob programming » du Mölkky, ou faire du toboggan pour schématiser des pipelines !
De plus, le BearStudio étant sponsor de l’édition 2023 du Camping des Speakers, nous avions à notre disposition un stand sur lequel nous avons pu présenter l’entreprise et faire découvrir [Start UI](https://start-ui.com/), notre starter open source de projet front.
## Le Stand : Rencontrer, échanger et partager notre passion
Qui dit stand dit goodies ! Nous avons réuni nos plus beaux goodies pour les partager avec les personnes présentes, et nous avons même concocté des stickers spécialement pour l’événement.

Les stickers des ours au camping !
Toute l’équipe était prête à accueillir les intéressés, discuter avec eux, et même leur présenter Start-UI en live.
Ce stand nous a permis de rencontrer beaucoup de gens, de revoir des personnes déjà rencontrées à d’autres événements, et tout ça dans une bonne ambiance et sous le soleil breton ! (oui oui vraiment !!)

Une partie de l'équipe derrière son stand
## Les conférences : Un kaléidoscope de sujets tech captivants
Avec plus de 50 speakers, le Camping des Speakers nous a offert une riche diversité de sujets passionnants. Des présentations sur les technologies utilisées au quotidien, comme l’IA avec une conférence sur le Speech to text ou des retours d'expérience inspirants, mais aussi des moyens originaux de faire comprendre des choses de notre quotidien dans la tech. Nous avons pu par exemple faire du minigolf avec altération de fonctions pour comprendre l’importance de l’accessibilité pour tous ou encore des descentes de toboggan dans la piscine pour illustrer les concepts de jobs et de pipeline parallèles. Les formats variés ont permis à chacun de trouver des conférences correspondant à ses intérêts, tout en favorisant le partage des connaissances et des expériences.


## L’avis des ours : Qu’en ont pensé les experts du BearStudio ?
### [Passez moins de temps à attendre la CI et plus de temps au bord de la piscine](https://camping-speakers.fr/sessions/passez_moins_de_temps_a_attendre_la_ci/) - Jean-Phi Baconnais & Guillaume Membré
“J’étais dans la piscine, j’ai fait du toboggan pour démontrer les concepts de job et pipeline parallèles et dépendants et ça c’est vraiment une très bonne manière d’apprendre de nouvelles choses !” - [Yoann Fleury](/fr/equipe/yoann-fleury)
_“C’est la seule conf que j’ai fait de ma vie où j’ai joué le rôle d’un job d’une CI le tout dans un toboggan d’une piscine, ça n’arrive qu’au camping des speakers”_ \- [Ivan Dalmet](/fr/equipe/ivan-dalmet)
### [Corn Hole 2 Turbo : De l'arduino pour l'apéro !](https://camping-speakers.fr/sessions/corn_hole_2_turbo/) - Paul Roye
_“Super intéressant d’autant plus que pour des side projects ou des projets persos, on a les mêmes problèmes qu'en pro ! (Faire un MVP vraiment minimaliste, toujours tester, etc...). On apprend tout en jouant à un jeu d’adresse, il n’y a rien de mieux”_ \- Dorian Delorme
### [🗣️ Zut ! J'aurais dû dire ça ! 🙊 Astuces pour parler avec aisance en public 🎙️](https://camping-speakers.fr/sessions/astuces_pour_parler/) - Willy Malvault & Sylvain Coudert
_“C'est pas un sujet tech et il y a d’autres conférences appréciées et mais j'ai vraiment bien aimé leur approche et leurs explications, c'était vraiment cool !”_ - Florian Gille
### [Vous pouvez venir à ce talk les yeux fermés](https://camping-speakers.fr/sessions/vous_pouvez_venir/) - François-Xavier Lair
_“J’ai pu découvrir l’utilisation d’un site web ou d’une app web avec un lecteur d’écran pour la 1ere fois de ma vie et j’ai pris conscience du chemin qu’il y a encore à parcourir pour faire des apps vraiment accessibles ! Et en plus j’ai appris des choses sur le HTML (l’utilisation d’un attribut alt vide sur une image par exemple, ça a une vraie utilité et je l’ignorais) donc c’était super !”_ - Fabien Essid
*“J'avais pu voir à codeurs en seine(lien) une conf similaire mais on avait l'écran du pc pour voir le site, et donc forcément on a tendance à regarder pour mieux comprendre le lecteur d'écran. La le fait que ce soit sans slides, on se rend vraiment compte de ce que représente l'utilisation d'un lecteur d'écran et à quel point c'est difficile quand le site n'est pas accessible”* \- Charlelise Fouasse
### [Mini golf pour une accessibilité numérique maximale](https://camping-speakers.fr/sessions/mini_golf_pour_une_accessibilite/) - Hervé Boisgontier
_“Un format hyper sympa ou l’on a fait une partie de croquet/minigolf qui permettait derrière de se mettre vraiment dans la peau d’une personne en situation de handicaps, et de se rendre compte qu'il y a plein de choses qu'on oublie quand on dev…”_ \- [Dylan Campbell](/fr/equipe/dylan-campbell)
### [Möbkky, le mob appliqué au Mölkky](https://camping-speakers.fr/sessions/mobkky_le_mob_applique_au_molkky/) - Benoît Masson & Gwendal Leclerc
_“L’idée de montrer l’intérêt du mob programming par le Mölkky était une idée très intéressante et pédagogique, ajouté à ça la bonne ambiance du jeu en lui-même, c’était un super moment !”_ \- [Hugo Pérard](/fr/equipe/hugo-perard)
---
En somme, au-delà de ces conférences grâce auxquelles chacun a pu repartir avec de nouvelles connaissances, ce Camping des Speakers était aussi l’occasion de partager de bons moments dans un contexte original. Nous avons notamment pu faire une partie de pétanque et passer quelques moments dans la piscine. Et cela nous a permis de revenir avec quelques anecdotes croustillantes.

---
### C'est quoi la minute kikoo de Renan ?
URL: https://www.bearstudio.fr/fr/blog/articles/cest-quoi-la-minute-kikoo-de-renan
Date: 2023-09-12
## D'où ça vient ?
La minute kikoo provient d'une remarque que je me suis faite en regardant l'émission Underscore\_ (sur [la chaine Twitch](https://www.twitch.tv/micode) de [Micode](https://www.youtube.com/@Underscore_)); un chroniqueur résumait très rapidement l'actualité de manière un peu fun et je me suis dit:
> *Ça serait quand même marrant d'avoir quelqu'un qui fait ça, mais en présentant toutes les technos / sites / outils inutiles que des gens ont un jour développé, montrer un peu la face cachée des sides-project qu'on peut trouver sur le web* 😃
Spoiler: j'ai pas trouvé ce concept, 😢 on arrête là ?
> _Non ! Si personne ne le fait, pourquoi ne pas le faire moi-même !_?
(et non, à aucun moment je me suis dit que personne ne le faisait parce-que c'était peut-être pas une bonne idée).
Depuis un moment, on a mis en place le [stream BearStudio](https://www.twitch.tv/bearstudiolive) où l’on se retrouve tous les premiers vendredi du mois, histoire de discuter autour de la veille réalisée par l’équipe et les viewers de la chaine, montrer les projets sur lesquels on travaille, et plus récemment avoir des invités…
M'est alors venu cette idée d’y inclure cet “happening”, cette petite rubrique de la minute kikoo et de profiter du stream pour voir si ça fonctionne ?
Le but serait de créer un moment assez court qui tranche avec le reste du stream, tout en restant orienté tech / outils de dev et qui soit surtout fun !
J'en parle autour de moi, ça fait marrer tout le monde; [Yoann](/fr/equipe/yoann-fleury) crée un générique de QUA-LI-TÉ en 20 minutes et on cale 5 / 10 minutes sur le prochain stream pour la première Minute Kikoo !
https://www.youtube.com/watch?v=hMk0aEMt5BM
La minute kikoo de Renan - 1
Résultat des courses, ça s'est super bien passé, pleins de retours positifs; la Minute Kikoo est maintenant programmée à chaque stream et disponible en [VOD sur notre chaîne YouTube](https://www.youtube.com/@bearstudio8378).
Venez nous voir tous les 1er vendredi du mois 😃 ça se passe sur [la chaîne Twitch du BearStudio](https://www.twitch.tv/bearstudiolive) !
Si jamais vous voulez une minute kikoo de Renan personnalisée, [contactez nous](/fr/contact), je fais également les mariages et bar mitzvah.
---
## Les Minutes Kikoo de Renan
- [La Minute Kikoo de Renan - 1](https://youtu.be/hMk0aEMt5BM) : 02 juin 2023 - [GitHub Actions Safe Space](https://github.com/charliegerard/safe-space) | [Extension VS Code Colors](https://marketplace.visualstudio.com/items?itemName=wwlorey.colors) | [Endless Horse](http://endless.horse/)
- [La Minute Kikoo de Renan - 2](https://www.youtube.com/watch?v=W-MFDnf88FQ&pp=ygUYbGUgbWludXRlIGtpa29vIGRlIHJlbmFu) : 03 mars 2023 - [VS Code Pets](https://marketplace.visualstudio.com/items?itemName=tonybaloney.vscode-pets) | [Pointer Pointer](https://pointerpointer.com/) | [Battery Buddy](https://batterybuddy.app/)
- [La Minute Kikoo de Renan - 3](https://www.youtube.com/watch?v=vROy1tts3Dw) : 3 février 2023 - [Desktop Goose](https://samperson.itch.io/desktop-goose) | [Clippy](https://marketplace.visualstudio.com/items?itemName=fleshywaffles.vs-code-clippy)
---
### Comment organiser une journée de conférence avec 1000 personnes ?
URL: https://www.bearstudio.fr/fr/blog/articles/comment-organiser-une-journee-de-conference-avec-1000-personnes
Date: 2023-02-15
## Les différents points à gérer
Bon... actif dans l'organisation [Codeurs En Seine](https://www.codeursenseine.com) je commence à avoir un peu de recul... Petit disclaimer : je ne suis pas à l'origine de cette journée de conférences. J’ai rejoint un groupe de bénévoles qui avait déjà fait une grosse partie du boulot et surtout l’événement avait déjà une bonne aura au niveau national. Mais je suis quand même plutôt fier d’avoir contribué à augmenter le nombre de visiteurs de 500 à plus de 1000 en quelques années !
Petit historique chiffré :

### Au cas où, Codeurs En Seine c’est quoi ?
Codeurs en Seine est une journée de conférences gratuites qui se déroule à Rouen, pour découvrir, apprendre et partager autour du monde du développement.
### Mais dis-moi Rudy, pourquoi tu nous racontes tout ça ?
Je me dis que ça peut toujours servir à quelques uns **MAIS SURTOUT** ça va nous servir à nous. En effet, comme toute association de bénévoles, en 6 ans on en a vu passer des bénévoles et c’est un peu chiant de devoir tout ré-expliquer donc voici la doc !
### Codeurs en Seine, la recette secrète !
Ce genre d’événement repose sur 3 gros piliers : les conférenciers, le public et le budget. Je vais détailler tout ça par ordre chronologique de prise en charge (même si certaines choses se font en parallèle).

#### Le budget
Forcément, avec les années, c’est plus facile d’avoir une idée du budget mais il y a forcément des changements qui ont un impact dessus d’une édition à l’autre. D’ailleurs si ça vous intéresse, on publie le détail du budget depuis quelques années :
- [Archive de Codeurs en Seine de l'année 2019](https://archive-201x.codeursenseine.com/2019/review-2019)
- [Bilan de l'édition 2019 de Codeurs en Seine](https://archives-codeurs-en-seine.netlify.app/archive-2020/2020/review-2019)
Mais sinon voici les gros postes de dépenses :
##### La location du lieu d’accueil
Lors du passage de l’université qui nous permettait d’aller jusqu'à 500 personnes au Palais des Sport de Rouen, ce poste de dépense est apparu, et en est aujourd'hui le plus gros poste.
L’avantage c’est qu’un certain nombre de points logistiques sont intégrés dans la prestation : location de chaises (parce que oui, pour asseoir 1000 personnes il en faut des chaises 😁), sécurité, installation, nettoyage, entretien des latrines etc..
Fortement lié au budget de la salle, il y a toute la partie son & vidéo. Nous travaillons depuis quelques années avec le groupe [En Scène](https://www.groupe-enscene.fr/presentation) qui a l’habitude de nous accompagner et qui a su s’adapter parfaitement à nos évolutions. Au début, on se chargeait d’enregistrer quelques panels, mais vu le boulot que ça représente on a décidé de laisser faire des pros. Cette année, nous avons également mis en place le [sous-titrage pour les sourds et malentendants](https://www.youtube.com/watch?v=V5vLYzVEWxA&list=PLbbYL6fWx8WyCEehq-sZx_iM3a4NVAoi-&index=4). Stream en direct pour l’année prochaine ?
Enfin, le reste du budget est alloué aux repas pour les visiteurs, des remboursements de frais de transport des intervenant.es et un peu de logistique type impression, sacs poubelles et gommettes.
Donc pour assurer notre budget, il faut trouver des sous !

Historiquement Codeurs en Seine a toujours été financé par des entreprises privées. C’est ce qu’on appelle des sponsors. Il y a 2 principales raisons pour qu’une entreprise donne de l’argent pour un tel évènement :
- Soutenir les communautés de dev et permettre à ce genre d'événement d'exister (oui ça paraît altruiste mais ça existe).
- Obtenir un retour sur investissement via de la publicité, trouver des profils à recruter et/ou vendre un produit ou une technologie à des développeurs.
##### Comment est-ce qu'on les trouve ?
Après plusieurs années, certains sponsors viennent d'eux-mêmes mais sinon il faut faire un peu de prospection en contactant des entreprises potentiellement intéressées. Généralement, ce sont des bénévoles avec des profils un peu business qui s’occupent de ça mais il y a aussi des profils plus axés “dev” qui vont simplement sourcer dans leur entreprise ou leur réseau perso. Si vous souhaitez sponsoriser Codeurs en Seine vous aussi, c'est [ici](https://www.codeursenseine.com/2023/sponsors) qu'il faut aller !
##### Qu’est ce qu’on leur dit ?
Globalement on leur évoque les raisons ci-dessus et on complète en détaillant ce qu’il y a dans le [dossier de sponsoring](https://drive.google.com/file/d/1zclVxBxeUZFUxX2kxVXCoAW8CnFr3p40/view).

Depuis quelques années, d’autres sources financières sont apparues :
- Les dons du public via [Helloasso](https://www.helloasso.com/associations/codeurs-en-seine/formulaires/1/widget) - ce sont de petits montant mais ça reste utile.
- La métropole de Rouen nous a accordé notre première subvention cette année. Merci à celles et ceux qui ont rendu ça possible.
#### Les conférenciers
Ok, on a le lieu, la logistique principale, maintenant il nous faut un programme !
Du coup pour ça il nous faut de bons sujets et des gens capables d’en parler. Il faut donc lancer un "appel à orateur" ou _call for paper_ en anglais.
C’est très connu et commun dans les communautés tech et après avoir essayé divers logiciels pour gérer ça, on a choisi [Conference Hall](https://conference-hall.io/) pour recueillir les sujets. L’une des raisons principales c’est qu’il est très facile pour un orateur de proposer ses sujets dans différentes conférences sans avoir à tout copier-coller. Et côté organisateur, l’interface est pensée pour faciliter la sélection. (oui c’est pas parfait mais c’est open source donc si t’es pas content, tu peux faire une PR).
Du coup concrètement, on prépare le CFP en définissant les thématiques, la durée des talks etc. On récolte les sujets de début juin jusqu'à début septembre.
En parallèle, on communique par mail et sur les réseaux sociaux, principalement Twitter, sur la possibilité de soumettre un sujet. Des bénévoles peuvent également aller contacter certains speakers pour leur dire de poster un sujet. Surtout si ce sont des personnes qui n’ont pas l’habitude de donner des conférences.
Concernant la ligne éditoriale, on essaye de composer une vision large de la tech, on va donc essayer d’avoir :
- un sujet par gros type ([front](/fr/prestations/developpement-web), [back](/fr/prestations/developpement-web), ops…)
- un sujet par techno principale (javascript, php, java etc),
- quelques sujets de niveau débutant, intermédiaire et expert
- quelques sujets de niche (hello [rust](/fr/blog/articles/rust) :p)
- quelques sujets avec des têtes ou des noms connus (parce que ça attire le public…)
- mais aussi avec des inconnus (histoire de ne pas avoir toujours les mêmes) et des locaux #Normandie (parce qu’on est là avant tout pour faire progresser notre communauté qui est principalement normande) !
Ce qui généralement nous donne un programme assez diversifié et il y en a pour tous les goûts.
Pour les keynotes, qui sont des conférences plénières, on essaye d'être à la fois original et d’aller puiser dans des industries et/ou thématiques éloignées de la tech mais qui peuvent résonner et apporter un point de réflexion intéressant. Cette année par exemple, on a eu [un faux astrophysicien](https://www.youtube.com/watch?v=duSKKN_53xQ&t=10s), [un homme politique](https://www.youtube.com/watch?v=SAbsGftoxxI) et un [ex-magicien devenu développeur](https://www.youtube.com/watch?v=V5vLYzVEWxA) (il ne le mentionne pas dans la conf mais je vous jure que c’est vrai).
Mais bon, revenons à nos moutons, une fois que l’appel à orateur est fini, s'ensuit la période de vote des bénévoles de mi septembre à début octobre. Ensuite on se fait une soirée pizzas durant laquelle on échange et on sélectionne les sujets.
À partir de là, des bénévoles s'occupent de mettre à jour le site et de mettre le [programme en ligne](https://www.codeursenseine.com/2022/programme). Certains préparent la communication autour de ça, d’autres s'occupent de communiquer avec les speakers, réserver des hôtels, préparer le repas speakers de la veille etc.
#### Le public
On a la chance d’avoir une communauté établie et un public fidèle mais il y a quand même du boulot pour faire venir les gens. Déjà il faut communiquer sur les canaux historiques mais d’années en années, il faut évoluer pour suivre les usages et attirer un nouveau public.
Historiquement la communication se faisait essentiellement par mail et sur Twitter mais depuis quelques années il y a le [Slack de Codeurs En Seine](https://go.codeursenseine.com/slack), d’autres channels communautaires, des posts Linkedin etc. Il y aussi des bénévoles qui prennent leur bâton de pèlerins et vont promouvoir Codeurs en Seine auprès de leur entreprise ou des écoles de la région.
Même si on a arrêté de donner des goodies Codeurs En Seine, il y a toujours des affiches et quelques stickers à produire. Au fur et à mesure des années, on a aussi tenu à simplifier le système des inscriptions mais il faut quand même gérer le processus.
## L’organisation sur une année ?
L’organisation d’une édition commence en général fin janvier/début février et se termine APRÈS l’event, c’est-à-dire mi-décembre.
Tout s’articule essentiellement autour de 3 outils :
- Un board Trello pour suivre les tâches
- Des channel Slack organisateurs pour communiquer entre nous
- Une réunion les lundis midi 2 à 4 fois par mois (en fonction de l'échéance restante avant le jour J) durant laquelle on passe en revue chaque action à faire, on essaye de trouver des volontaires et on prend des décisions - clairement, c’est pas sur cette partie où nous sommes les meilleurs mais dans l’ensemble on se marre bien et on arrive à avancer, c’est ça qui compte.


### La veille
La veille c’est la préparation !
On s’occupe de se faire livrer le matériel et on installe les salles. Pour les salles de conférences, les principales tâches consistent à vérifier le travail des prestataires pour tout ce qui est logistique (chaises, pupitres, électricité) et son/vidéo (test micro, affichage).

Pour la partie accueil des visiteurs, on organise les files, on affiche de la signalétique, on briefe les bénévoles qui seront en charge de scanner les visiteurs.
Pour la partie sponsors, on vérifie les tables mises à leur disposition et tous les branchements nécessaires. On les accueille pour leur permettre d’installer leur stand en avance.

On prépare également une salle à la disposition des orateurs pour qu'ils puissent s'isoler/travailler/répéter/discuter entre eux tout au long de la journée.
Enfin, il nous reste la partie préparation des points repas et de la logistique autour de ça (j’avoue que je connais moins cette partie donc je peux moins détailler :p).
En fin de journée, certains bénévoles vont chercher des orateurs à la gare pour les amener à leur hôtel, puis au repas des Speakers qui permet à tout le monde - organisateurs et orateurs - de commencer officieusement l’event dans un moment convivial (même si certains sont fatigués ou d’autres stressés).
### Le jour J
En plus des organisateurs présents tout au long de l’année, on renforce l’organisation avec des bénévoles jour J (qu’il faut trouver avant bien entendu). Ça commence donc par un rendez-vous vers 7h du matin afin de finir les derniers préparatifs et briefer les équipes. Ensuite tout le monde se répartie entre gestion de salle, speakers, sponsors, visiteurs, nourriture, vidéos, photos et gestion des imprévus…

### Après le jour J
Même si pour beaucoup, Codeurs en Seine se termine en fin de journée, il reste encore des tâches pour les organisateurs, à savoir :
- Payer les prestataires et les frais de déplacement des orateurs
- Communiquer pour remercier tout le monde (visiteurs, sponsors, orateurs et bénévoles)
- Récupérer les enregistrements, faire le montage vidéo et mettre les VOD sur YouTube
- Ranger le matos qu’on a balancé en vrac dans les voitures le soir
- Essayer de capitaliser sur les problèmes qu’on a rencontrés pour mieux faire l’année suivante
- Publier les photos de l’événement
- …
## Quelques tips
Avant de terminer je vais lister quelques petits conseils qui peuvent servir à tous et à toutes :
- On a toujours besoin de bénévoles donc n’hésitez pas à vous proposer si ça vous dit. On est clairement pas les meilleurs sur l’onboarding des nouveaux mais on n’est pas méchants :).
- En tant que bénévoles, n’hésitez pas à proposer votre aide pour prendre une tâche mais n’oubliez pas qu’il est important de communiquer sur votre avancement (y compris sur du non avancement). Tout le monde fait comme il peut donc on ne vous en voudra pas de ne pas toujours pouvoir accorder du temps à l’orga, mais pour éviter de créer des tensions ou de la frustration, il ne faut vraiment pas hésiter à se manifester plutôt que de disparaître ou de faire l’autruche…
- En tant qu’association, il y a pas mal de produits ou d'outils en ligne d’ordinaire payants mais qui sont gratuits pour les assos. Il faut souvent juste faire une demande dans un recoin un peu obscur du site du produit (pour Codeurs En Seine, on a G Suite, Slack et Netlify pour le site web en version gratuite).
- Pour éviter de devoir systématiquement programmer des talks animés par les entreprises qui sponsorisent l’événement, on a eu l’idée un peu diabolique de créer un pack “platinium” avec un tarif très élevé pour les sponsors qui souhaiteraient vraiment s’assurer une intervention le Jour J. Morale de l’histoire : personne n’a jamais pris cette option.
Voilà, je ne sais pas trop comment conclure cet article à part en remerciant les fondateurs de Codeurs En Seine et tous les organisateurs et bénévoles depuis tant d'années… Je vous assure que cette conférence a un impact énorme sur ma vie professionnelle (avant même que je rejoigne l’organisation) et que les 10 dernières années de ma vie n'auraient pas du tout été les mêmes si Guillaume Lours, Yann Petit et Youen Chene n'avaient pas eu cette brillante idée.
Alors merci !!!

---
### Brève 13 - Exécuter et déployer un projet JHipster avec Java 17
URL: https://www.bearstudio.fr/fr/blog/articles/deployer-jhipster-java-17
Date: 2022-07-05
Cette brève est une traduction de l’[article publié par Quentin sur dev.to](https://dev.to/qlerebours_/upgrade-your-jhipster-project-to-java-17-3al6).
Dans ce court article, je vais expliquer comment exécuter et déployer un projet JHipster en utilisant une autre version de Java que la version standard utilisée par JHipster (Java 11 actuellement).
## Etape 1 : Faire tourner son projet JHipster sur la version Java ciblée
### Utilisez la bonne version de Java en local
Tout d'abord, vous devez avoir la version Java ciblée dans votre environnement local. Si vous utilisez [SDK man](https://sdkman.io/), vous pouvez exécuter :
- `sdk list java`
- Une fois que vous avez trouvé la version cible, installez-la avec `sdk install java 17.0.2-open` (par exemple)
- Enfin, lancez `sdk use java 17.0.2-open` pour l'utiliser dans votre terminal
💡 SDK man est un excellent outil pour gérer plusieurs versions de Java sur votre environnement. Il permet d'installer facilement les versions et de passer d'une version à l'autre.
### Définissez la bonne version de Java pour le projet
Une fois que vous utilisez la bonne version de Java localement, il vous suffit de modifier la version cible dans le projet. Si vous utilisez Maven, il suffit de changer `17` dans le `pom.xml`
🎉 C’est prêt, vous pouvez essayer d'exécuter le projet avec `./mvnw`
💡 Si vous voyez une erreur "Invalid target release 11", c'est probablement que votre version locale et celle du projet ne sont pas synchronisées. Elles doivent être identiques (17 dans mon cas).
## Étape 2 : Corriger la CI
Si vous utilisez une CI et que votre CI utilise l'image Docker `jhipster/jhipser:latest` pour exécuter le projet et les tests, cela ne fonctionnera plus car cette image Docker est basée sur `eclipse-temurin:11-jre-focal` qui utilise Java 11.
Cela signifie que vous devrez recréer votre propre image Docker basée sur Java 17, mais ne vous inquiétez pas, ce n'est pas compliqué :
- Clonez le projet [generator-jhipster](https://github.com/jhipster/generator-jhipster) sur Github
- Ouvrez le Dockerfile qui se trouve à la racine du projet
- Modifiez l'image de base en `eclipse-temurin:17-jre-focal`
- Créez un dépôt sur le hub docker. Supposons qu'il s'appelle `myOrganization/jhipster-java-17`
- Créez la nouvelle image avec `docker build . -t myOrganization/jhipster-java-17:latest`
- Poussez la toute nouvelle image vers le hub avec `docker push myOrganization/jhipster-java-17:latest`
- Enfin, changez l'image docker utilisée dans votre CI en `myOrganization/jhipster-java-17:latest` et quand votre CI sera ré-exécutée, elle fonctionnera à nouveau
## Étape 3 : Modifiez votre environnement Cloud
Au [BearStudio](/fr/prestations), nous utilisons [CleverCloud](http://clever-cloud.com/) qui permet de modifier la version Java cible très facilement grâce à la variable d'environnement `CC_JAVA_VERSION` qu’il faut mettre à jour à la version 17, avant la sauvegarde de vos changements.
**C'est fait, votre projet JHipster devrait maintenant fonctionner sur Java 17 🎉**
Si vous n'utilisez pas encore JHipster, vous pouvez [apprendre à générer votre premier projet ici](/fr/blog/articles/jhipster-generateur-projet-hipsters).
---
### La checklist SEO technique pour lancer un site web
URL: https://www.bearstudio.fr/fr/blog/articles/checklist-seo-technique
Date: 2022-06-27
Si la création d’un site web est (presque) **indispensable** pour développer une **notoriété en ligne**, il est important de respecter certaines **règles de conception** si vous souhaitez gagner de la visibilité en vous **positionnant sur Google**.
Cet article est pensé pour les **porteurs de projet** qui souhaitent lancer leur premier site web ou pour les **développeurs juniors** qui souhaitent **respecter ou améliorer le SEO** de leurs clients mais aussi pour toutes les personnes intéressés par le SEO !
## Pourquoi respecter les critères de référencement de Google ?
Une grande majorité des recherches sont effectuées via Google ([90% en France](https://www.blogdumoderateur.com/chiffres-google/)). Donc pour **maximiser votre visibilité** en termes de référencement naturel, il est évident qu’il faut **suivre les recommandations** du géant. D’autant plus que suivre les **critères de Google** permet de **gagner des positions** sur l’ensemble des moteurs de recherche.
Au vu du nombre de sites présents sur la toile (2 milliards en 2021 d'après satista), les **moteurs de recherche** ont tout intérêt à **réguler** le nombre de pages qu’ils indexent et à faire **ressortir les pages** qu’ils estiment **qualitatives** en première page du résultat de recherche.
Ce nombre étant de plus en plus important, les moteurs de recherche peaufinent leurs **algorithmes** pour être plus **exigeants** avec des **critères de qualité** toujours plus élevés.
On pourrait établir une longue liste de l’ensemble des critères pris en compte par Google. Parmi les plus connus on retrouve la qualité du contenu, la sémantique, la hiérarchie des informations, l’expérience utilisateur, le nombre et la qualité des liens externes, le maillage interne et la vitesse de chargement.
Dans cet article, je vais me concentrer sur l’**aspect technique on-site** du SEO en établissant une petite **checklist de démarrage** d’un projet de site web.
## Les critères SEO techniques on-site à respecter sur son site web

### Optimiser la performance de son site
S’il y a bien un **critère d’expérience utilisateur** à ne pas négliger, c’est la **performance** d’un site web. [D’après Deloitte](https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Consulting/Milliseconds_Make_Millions_report.pdf) une diminution de 0,1 seconde de temps de chargement augmenterait le taux de conversion de 8%.
Pour tester la performance d’un site, vous pouvez passer par Lighthouse qui est accessible via le menu “Outil de développement” de Chrome.
Pour avoir un score pertinent, je vous conseille de tester avec plusieurs outils. Vous pouvez utiliser [PageSpeed Insight](https://pagespeed.web.dev/) et [GTmetrix](https://gtmetrix.com/) (qui est d’ailleurs un peu trop "gentil").

Exemple de résultat d’un test sur PageSpeed Insights pour la landing page de [Start UI](https://github.com/BearStudio/start-ui-web).
En utilisant ces outils vous obtiendrez les **points clés** pour **améliorer la performance** de votre site web. Parmi les points récurrents on retrouve :
**La compression des images**
Vous pouvez utiliser [tinypng](https://tinypng.com/) pour **réduire la taille de vos images**. Si vous êtes sur WordPress, vous pouvez passer par un plugin comme [imagify](https://imagify.io/fr) qui optimise automatiquement toutes vos images.
**Dimension des images**
Évitez d’utiliser des images dimensionnées en 10 000x10 000 qui, même compressées, seraient bien trop lourdes.
**Format des images**
**Privilégiez le format WebP** qui est bien plus léger que le JPG ou le PNG. Sur WordPress vous pouvez utiliser imagify qui convertit automatiquement vos images.
**Chargement différé (lazy loading)**
Le **lazy loading** permet de faire charger les ressources seulement lorsqu’elles sont utiles. Par exemple les images hors écran ne chargeront qu’à leur affichage suite au défilement de la page par l’utilisateur.
Pour utiliser le lazy loading vous pouvez avoir recours à un [script JS](https://www.andreaverlicchi.eu/vanilla-lazyload/), l’attribut loading ou encore un plugin comme WP Rocket si vous êtes sur Wordpress.
L’important, c'est vraiment que le **contenu** textuel de la page ne soit **pas trop retardé par le chargement** de scripts, de feuilles de styles ou autres.
**Minimisation du code**
Il ne faut pas sous-estimer l’impact du **poids de votre code JavaScript et CSS**. Vous pouvez le compresser facilement en l’entrant sur un outil comme [Refresh SF](https://refresh-sf.com/). Si vous êtes sur WordPress vous pouvez optimiser l’ensemble de votre site avec un plugin comme WP Rocket.
Pour éviter d’avoir un code trop lourd, vous pouvez également retirer les plugins que vous n’utilisez pas.
Il existe évidemment beaucoup plus de critères, à vous d’aller explorer les résultats de vos tests de performances !
### Les balises à utiliser en SEO
Les balises sont des **tags codés en HTML** qui permettent d'apporter des informations importantes aux moteurs de recherche et utilisateurs. En SEO vous risquez d'être fortement pénalisé si vous n'utilisez pas les **balises importantes pour le référencement**.
#### La balise de méta description
Les balises meta sont des **balises HTML situées dans la balise head** du code et qui permettent d’y ajouter des **meta-données** (des informations sur la page en question).
La balise de méta description permet de **décrire le contenu d’une page** web sur la SERP (Search Engine Results Pages ou Page de résultats d’un moteur de recherche).
Concrètement, ça donne ça pour le site du BearStudio :

Pour l’intégrer dans une page web, le code s’insère dans la balise head comme ça :
` `
Vous pouvez aussi passer par un plugin comme Yoast SEO, SEOPress ou Rank Math pour intégrer facilement vos meta description si vous utilisez un CMS.
La **rédaction d’une meta description est primordiale** pour le référencement étant donné qu’elle influe directement sur le **taux de clics** de votre page sur la SERP. Pour être efficace, la description doit faire entre **140 et 160 caractères** et contenir un **mot clé** sur lequel vous souhaitez vous positionner.
#### La balise title
La balise title correspond au **titre de votre page** affiché sur la SERP et dans l’onglet du navigateur. En reprenant l’exemple du BearStudio on obtient ça :

Le title se retrouve dans la balise head comme ça :
` BearStudio `
Comme pour la méta description, le title peut se modifier très facilement sur un CMS en utilisant un plugin comme Yoast SEO.
Pour être efficace, la balise title doit contenir le **mot clé principal** de la page et ne pas dépasser les **65 caractères**. Elle doit donner envie de cliquer et être pertinente par rapport au contenu de la page.
Attention à ne pas confondre le titre 1 (balisé par le tag `
`) qui correspond au premier titre de la page avec la balise title qui apparaît dans l’onglet du navigateur.

#### La balise alt
Google n’est pas encore assez intelligent pour comprendre vos images. Heureusement vous pouvez l’aider en décrivant votre image grâce au **texte alternatif**. Ce texte, sous la forme d’une balise alt, permet également de remplacer l’image si celle-ci ne charge pas. Au delà de l’aspect SEO, elle est surtout utile pour les personnes malvoyantes utilisant un lecteur d’écran. C’est d’ailleurs pour ça qu’elle existe.
Pour utiliser la balise, il suffit d’**ajouter l’attribut alt** dans les propriétés de l’image, comme ici :
``
Sur les CMS, vous pouvez ajouter l’attribut alt directement depuis le back-office lorsque vous importez une image.
#### Les balises Hn
Les balises Hn permettent de **créer une** **hiérarchie des titres** avec H1 comme titre principal et H2, H3, Hn… comme sous-titres classées du plus au moins important.
Pour baliser un texte en Hn c’est très simple, prenons le H1 de cet article :
`
La checklist SEO technique pour lancer un site web
```
Même si de prime abord la solution semble un peu plus verbeuse, il faut peu de temps pour s'apercevoir qu'elle permet surtout d'instantanément identifier les différentes composantes et les liens de parenté entre chacune.
`article`, `article--sponsorised`, `article__photo` et `article__presentation` sont liés les uns aux autres, tandis que `card`, `card__img` et `card__text` forment un autre groupe identifié, alors que `logo` est une dernière classe isolée n'ayant aucun lien de parenté avec les autres éléments cités.
Faisant la part belle aux concepts tels que le *Don't Repeat Yourself*, la convention BEM apporte clarté, sécurité et compréhension accrue de la structure du code.
Il peut demeurer fastidieux d'identifier exactement le rôle de chacun, non seulement d'un point de vue relatif mais surtout global et inhérent au projet, afin de comprendre rôle, comportement et implantation de chacun. Et vous avez de la chance, le namespacing est là à la rescousse !
## Namespace oddity
Le Namespace correspond au préfixage des classes dans le but d'ajouter précision et compréhension quant à leur usage et leur place au sein de votre code.
Personnellement, j'aime à décomposer cette structure en 4 préfixes principaux, qui peuvent être complétés et aggrémentés suivant les besoins et les ressources de votre projet :
- **Layout : `l-`** :
Il regroupe tous les éléments faisant partie de la mise en page. C'est l'une des parties générales et structurelles de votre UI, utilisée généralement sur tous les écrans de votre site.
Exemple : `l-header` `l-typography` `l-sidebar` `l-contact` `...`
- **Object : `o-`** :
Il signifie que cet élément est un objet. C'est une partie d'UI déterminée et identifiable (_"Ceci est un bouton", "Ceci est une modale"..._) qui peut être utilisée de manière répétée dans votre projet.
Exemple : `o-buttons` `o-cards` `o-panels` `o-breadcrumbs` `...`
- **Component : `c-`** :
Il signifie que cet élément est un composant. C'est un élément spécifique (parfois même abstrait), qui peut être utilisé de manière ciblée, sans discernement de sa position dans le code.
Exemple : `c-media` `c-input-slider` `c-checkbox` `c-avatar` `...`
- **Utility : `u-`** :
C'est une classe utilitaire. Elle est utilisée pour écraser et modifier le comportement des éléments ciblés.
Exemple : `u-text-align` `u-display` `u-spin` `u-no-margin` `...`
```html


## 2. Decoration Workshop
##### Week of October 13-20
Second phase: **Halloween decorations.**
After a brief _Instagram inspiration_ session (and a few critical failures), we finally got the hang of it.
Tip of the day: gluing with water is eco-friendly... but it has a mind of its own and requires a bit of patience to hold! A bit like testing a new code snippet: sometimes it works on the first try. And sometimes you need to tweak a few details for everything to fit together perfectly.



### 3. Garland Workshop
##### Week of October 20-27
Time for **creative recycling!**
Toilet paper rolls, scraps of colored paper, a marker, and a piece of string later. And there you have it — an army of little ghosts, pumpkins, bats, and other strange creatures ready to invade the office.
Some characters looked terrifying, others... a bit too cute to be scary.
But the spooky vibe was there between two coffees and three commits on _Lea English_ (you can read the UX case study [here](/en/blog/posts/lea-english-case-study))!



## 4. Werewolf Night
##### October 30
No full moon without **Werewolf!**
Everyone under their blanket with a hot chocolate or their dinner. Connected on the [Wolfy](https://wolfy.net/fr) website for an evening full of digital betrayals and intense debates about "who's the werewolf?", "who will be the mayor?", or "who's Cupid? We have scores to settle...".

And a little round of GarticPhone that had nothing to do with Halloween to end things on a high note (drawings made with a trackpad and questionable talent that made us laugh even harder!).


In short, a packed October at BearStudio: pumpkins, code, laughs, and a few scares... but above all, a team of bears that knows how to turn _bugs_ into candy and _pull requests_ on [Start UI](/en/blog/posts/start-ui-opinionated-ui-starter) into moments of sharing.

---
### Why did we create ui-state?
URL: https://www.bearstudio.fr/en/blog/posts/why-did-we-create-ui-state
Date: 2025-10-16
Why did we create [ui-state](https://github.com/BearStudio/ui-state), a TypeScript library to manage ui state display? It all started after reading an excellent article by [Dominic Dorfmeister, aka TkDodo](https://x.com/TkDodo) (we also recommend checking out [his other posts on his blog](https://tkdodo.eu/blog/)).
In the article [Component Composition is great btw](https://tkdodo.eu/blog/component-composition-is-great-btw), TkDodo highlights a recurring problem: managing UI states (`loading`, `error`, `empty`, `success`, etc.) in a way that is **readable, maintainable, and type-safe** without making your component structure explode.
The typical starting point.
You start by writing a simple component:
```tsx
export function ShoppingList() {
const { data, isPending } = useQuery(/* ... */);
return (
Welcome 👋
{data?.assignee ? : null}
{isPending ? : null}
{data
? data.content.map((item) => )
: null}
);
}
```
At first glance, everything seems to "work."
But things get messy quickly:
- Can we have both `data` and `isPending` at the same time?
- Does the absence of `data` mean an error or an empty list?
- What happens if `data` is present but empty?
You end up juggling several flags (isPending, data, isError, etc.) that can make two parts of the UI appear simultaneously, when that wasn't the intent.
**It becomes hard to read, test, and maintain.**
## TkDodo's proposed solution
TkDodo suggests a clearer refactor based on `early returns`:
```tsx
function Layout(props: { children: ReactNode; title?: string }) {
return (
Welcome 👋 {props.title}{props.children}
);
}
export function ShoppingList() {
const { data, isPending } = useQuery(/* ... */);
if (isPending) {
return (
);
}
if (!data) {
return (
);
}
return (
{data.assignee ? : null}
{data.content.map((item) => (
))}
);
}
```
This version is **much clearer**, each state corresponds to a single render.
But there's a tradeoff: **You have to extract the layout into a separate component, and what if you don't want the entire screen to change?**
`Layout` is duplicated in every branch. You also need to extract typing logic for the `Layout` props. And if you want part of the interface (like a header or sidebar) to remain constant between states, or certain `Layout` parts to depend on the state, your code structure starts to grow complex again.
## What we wanted: a single, well-typed, active state, reusable anywhere
At [BearStudio](/en), we wanted to keep the same core principles:
- Only one active state at a time
- Exhaustive type safety
- Readable display logic
…but **without breaking up the JSX** or restructuring the entire render around state cases.
We wanted to be able to say:
> "Give us the current state, we'll handle it. Just make sure we cover every case."
## That's why we created ui-state
With `ui-state`, you transform the response from a `useQuery` (or any data source) into a single, explicit state, based on a single call to `getUiState`.
```tsx
import { getUiState } from '@bearstudio/ui-state';
export function ShoppingList() {
const query = useQuery(/* ... */);
const ui = getUiState((set) => {
if (query.status === 'pending') return set('pending');
if (!query.data || query.data.content.length === 0) return set('empty');
return set('default', { data: query.data });
});
return (
Welcome 👋
{ui
.match(['pending', 'empty'], () => '')
.match('default', ({ data }) => data.title)
.exhaustive()}
{ui
.match('pending', () => )
.match('empty', () => )
.match('default', ({ data }) => (
<>
{!!data.assignee && }
{data.content.map((item) => (
))}
>
))
.exhaustive()}
);
}
```
What we gain from this:
- **A single, well-defined state**, always up to date.
- **Type exhaustiveness** via `.exhaustive()` ensures no case is forgotten.
- **Automatic type narrowing** from TypeScript — for example, data is no longer optional since we've verified its existence.
- **Full rendering freedom**, without restructuring JSX around states.
- **Better testability**, you can test each UI state independently.
Same concept as in TkDodo's article, but **no need to split into multiple components or wrap your entire JSX around state handling**.
You keep **clear logic and intact composition**.
🔗 GitHub: https://github.com/BearStudio/ui-state
---
### Lea English Case Study
URL: https://www.bearstudio.fr/en/blog/posts/lea-english-case-study
Date: 2025-07-03
## Project Overview
Lea English is an online learning platform created by Léa, a **professional multilingual language coach** who speaks five languages fluently. She has built a community of over **350,000 French-speaking learners.** Her teaching approach emphasizes effective learning of everyday English through practical conversational skills.
Unlike traditional grammar-focused courses or excessively gamified apps, her minimalist approach prioritizes essential speaking skills and natural language use. **The goal is to achieve quick, real-world fluency.**
With a **proven web application and feedback from her paying users,** Léa partnered with our team. This collaboration enabled us to evolve this learning experience through **a thoughtfully designed mobile app** centered on user needs.
## The Challenge / Context
Language learners often face **overloaded**, **grammar-heavy** programs that limit their conversational progress. Other methods, conversely, rely too heavily on **gamification at the expense of effectiveness.**
**Traditional apps** generally target **beginners,** without truly enabling an effective transition to intermediate or advanced levels.
Furthermore, **learners frequently lack** practice in **real conversations** and face **difficulties communicating** confidently in **real-life situations.**
## Our Role - BearStudio
##### Product Designer (UI/UX Designer), responsible for:
- **User research** (expert interviews, usability feedback, competitive analysis)
- **Information architecture** and **user journeys**
- **Wireframing** and **prototyping**
- **Usability testing** and **design iterations**
- **Iterative collaboration** with **developers** on technical challenges and idea feasibility
##### Developers:
- **Development** of the app in React Native / Expo, for deployment on Android and iOS
- **Design** of **animations** to enhance the app experience
- **Implementation** of the conversational bot feature (based on OpenAI's API)
- **Integration** of **feedback** from the product designer and Léa
- **Use** of **shared components** from Storybook and Figma to ensure consistency and efficiency in the interface
## Research & Key Insights
#### Kickoff Workshop
To fully leverage our client's deep knowledge of her users, we held a **focused 3-hour collaborative workshop with Léa**. She shared **extensive feedback** collected directly from **her users**. This data is rich and qualitative. It comes from Léa's field experience and her direct interactions with **over 350,000 engaged learners.** Thanks to this information, we were able to quickly identify **key user needs**. It also helped validate the main pain points encountered. We sketched **initial ideas in real time,** as insights emerged, nourished by Léa's invaluable teaching experience.

General sketch from our online workshop with the client
We complemented these valuable client-provided insights with a **targeted competitive analysis** (studying platforms like Duolingo, iTalki, and Simpler). [This allowed us to identify specific UX best practices and areas for improvement.](/fr/blog/articles/pourquoi-lexperience-utilisateur-est-elle-importante) This approach helped us strengthen the solid foundations laid by Léa. We combined her user-centered feedback with industry standards. Thanks to this, we were able to clearly define a strong direction for our design work.
#### Additional Details on Initial Data and Research
##### Competitive Analysis
To better understand the market, we studied several platforms such as Duolingo (excellent gamification, but limited speaking practice), iTalki (live tutors, but scheduling and lesson content that can feel fragmented), and Simpler (primarily targeting beginners through a grammar-based approach, which doesn't deliver fast results in everyday communication).
From this competitive analysis, it became clear that the app to be designed needed to demonstrate **effectiveness** by emulating our client's teaching method and improving **real-time feedback**. Since private lessons are often expensive or inflexible, our goal was to create an integrated solution combining the best of both worlds: interactive online lessons and on-demand exercises, while maintaining an engaging yet **results-oriented** format.
##### User Feedback on the First Version of the Web App
**Over 400 learners** participated in feedback through surveys, revealing several pain points:
- **Missing features** \- Users made clear suggestions to improve their learning routine on the existing app.
- **Motivation and consistency** \- Many struggled to stay consistent without concrete progress indicators and notification features.
**Our in-depth analysis** of the **web app**, cross-referenced with feedback from regular **paying users**, highlighted several friction points:
- **High cognitive load**, making usage sometimes tiring or discouraging.
- **Lack of fluidity** in user journeys, undermining the overall experience.
- **Usability issues**, with key interactions deemed unintuitive or unnecessarily complex.
These obstacles significantly reduced engagement and accessibility. Beyond UX issues, we also identified **technical flaws, including security vulnerabilities and recurring functional bugs**.


##### Some of Our Observations
- **Excessive clicks in tests -** Users had to chain multiple clicks to move to the next step, adding unnecessary delays and harming the flow of the experience.
- **Asynchronous audio experience -** The transcription did not highlight words in real time during playback, making it difficult for users to follow along.
- **Limited flash card interaction -** The flip mechanism was unintuitive and did not support a smooth, continuous learning experience.
#### Target Audience
- Adult learners ranging from **complete beginners (A1) to advanced (C1).**
- Users who prefer **practical, effective learning** rather than grammar-focused approaches.
- People looking to develop their speaking confidence through **regular, interactive, conversation-oriented practice.**
We ensured that design decisions were aligned with **real user needs**. By mapping user behaviors, goals, and frustrations, the research provided a better understanding of the first version's limitations. These limitations mainly concerned usability and the ability to sustain user engagement. Furthermore, this analysis served as a reference throughout the design process. It helped prioritize the necessary improvements. These aimed to enrich the overall experience, streamline interactions, and increase user satisfaction.
## Clear Approach: Guiding Principles and Benefits
##### Seamless Integration to Reinforce Learning
Vocabulary, audio, and interactive exercises are **tightly connected**, creating a cohesive ecosystem. Users naturally reinforce their skills through **varied** and **interconnected interactions,** promoting effective memorization and assimilation.
##### Personalized Learning Experience
By leveraging the user's level, preferences, and behaviors, the app consistently delivers tailored content and interactions, significantly boosting motivation and learning effectiveness. This leads to **user-centered personalization**.
##### Intuitive and Engaging UX
Prioritizing simple, clear, and intuitive interactions ensures minimal cognitive load, allowing users to focus fully on language learning rather than navigation. The integration of gamified interactions, daily limits, clear progress indicators, and immediate feedback motivates users to maintain regular language practice. This leads to **continuous learning motivation**.
##### A Flexible Approach Accessible to All Levels
While addressing a broad audience, the app allows users to choose their learning type while following a defined progression to reach the next level. This leads to **sustained platform engagement**.
## Design & Iteration
#### Initial Wireframes
We used wireframes to define the app's features and structure its main sections as well as its information architecture.
- **Interactive Cards** - a short test to ensure the gesture was intuitive for users from the start.
- **Audio Listening** - testing quick access to audio levels desired by the user.
- **AI Chat** - testing clarity of distinction for users between the daily interactive conversation and past conversations, which needed to be clearly indicated as inactive.

#### Usability Testing and Validation
We conducted internal **usability testing** sessions with **six colleagues**. These tests were based on low-fidelity wireframes. We focused on task-based scenarios. The goal was to quickly evaluate the clarity of interactions, navigation intuitiveness, and overall engagement. This feedback fueled rapid design iterations.
One of the **adjustments** concerned card behavior, with the addition of a "Don't learn" button, requested by users for cases where they no longer wanted to practice a word or expression.
## Design Explained
#### Branding and Design System
Lea English already had **a clear and well-defined visual identity**, which we naturally integrated into our custom design system. We built upon components from [Start UI Figma](/en/blog/posts/start-ui-opinionated-ui-starter), an open-source Figma library that we designed and use internally.
The components we use in Figma are already implemented in [Start UI Native](/en/blog/posts/start-ui-opinionated-ui-starter). This library uses technologies like **TypeScript, React** and **Ficus UI.** Thanks to this, developers can immediately accelerate the implementation phase after design finalization. Furthermore, it ensures consistency for future features to come.

#### UX Feature Analysis
###### 1\. Daily Vocabulary Cards
- **Interactive Flip Cards**
- Users interact via an **intuitive flip gesture** to **reveal the translation**, reinforcing active recall — a proven learning technique.
- The flip interaction immediately stimulates cognitive attention, promoting **better retention.**
- **Daily Limit**
- **Restricting** to 5 cards per day manages cognitive load, **prevents fatigue**, and improves **long-term retention.**
- This introduces **a gamification element,** creating anticipation and establishing a daily routine.
- **Progress Indicator**
- Clearly visible **progress** counters or bars encourage regular user engagement and provide **immediate feedback** on daily goals achieved.

###### 2\. "Review" Feature
- **Synchronized Listing**
- Words flipped in the daily cards **automatically appear** in the review section. These are clearly marked based on the user's interaction (green for known, red for unknown).
- This synchronization ensures a **seamless integration** between learning and vocabulary review, **reinforcing assimilation.**
- **Personalized Vocabulary Management**
- Users can manually add new words to **customize their vocabulary list,** enhancing the personalization of their learning experience.
- Options such as marking a word as "known" or removing it with "don't learn anymore" allow for **efficient management** of words to practice.
- **Flexible Display Options**
- Users can choose to display words in French or English first, according to their **learning preferences**.
- **Audio and Examples**
- Users can **listen to pronunciation** directly in the review section, supporting auditory learning.
- Contextualized word or expression examples help reinforce understanding and correct usage.

###### 3\. "Listen" Feature
- **Personalized Audio Recommendations**
- Suggested audio content is highlighted at the top of the screen based on **the user's English level** (beginner, intermediate, advanced), ensuring content relevance.
- Each audio is clearly labeled by language level, type (dialogue or monologue), and general theme, facilitating quick and informed selection.
- **Visual Progress Tracking**
- Already-listened audio content is indicated in green, offering immediate visual feedback on the user's progress.
- **Advanced Filtering**
- Users can filter audio by favorites, offline downloads, and levels, enabling effective personalization of listening sessions.
- **Quick Access Features**
- Quick download and favorite (heart) options are directly accessible from the audio list, simplifying interactions and improving usability.
- **Detailed Audio Screen**
- Quick action buttons for downloading, adding to favorites, or marking as listened offer more practical usage.
- Interactive transcriptions allow instant switching between English and French, with synchronized text highlighting to accompany reading and listening.
- New vocabulary in transcriptions is highlighted in uppercase and bold to facilitate immediate recognition and learning.
- **Fixed Audio Control Bar**
- Audio controls remain permanently visible during scrolling, with integrated options for adjusting playback speed and showing or hiding the transcription, thus improving user comfort and control.

###### 4\. AI Conversation: "Practice"
- **Daily AI Conversation Sessions**
- Users participate daily in guided AI conversations on predefined topics. This practice encourages active grammar use and conversational skill development.
- Real-time corrections provided by the AI offer immediate feedback, allowing users to quickly identify their mistakes and learn from them.
- The user has quick access to a translator during the conversation.
- **Error Highlighting**
- Grammar or syntax errors are clearly flagged and corrected during exchanges, helping users internalize correct language structures.
- **Structured Daily Topics**
- Varied daily themes ensure rich exposure to different vocabularies and grammatical contexts, keeping the exercise relevant and motivating.

#### Complete Launch Management and Visual Design
In preparation for the public release, we designed all the visual assets. This includes **detailed app previews**, optimized for different device formats on **the App Store and Google Play.** Additionally, we managed **the entire launch process** internally. We thus ensured consistent brand representation. Furthermore, we provided a smooth onboarding experience for users across all platforms.
#### Iterative Launch and Feature Integration
The initial release, **in April 2025,** strategically targeted approximately **300 users** on launch day to create a controlled testing environment. This early feedback was invaluable, allowing us to iterate quickly and improve [the user experience](/en/services/ux-design) based on direct feedback.
###### Learning Pace Customization
Users requested a feature allowing them **to choose the number of new cards to flip each day**, in order to adapt their learning to their own pace.
###### Speech-to-Text Feature
Users also requested **a speech recognition feature** for AI-generated conversations, which was designed and successfully integrated.
###### Geographic Expansion
Community feedback revealed **demand from other regions**. We therefore expanded the app's availability to several countries beyond France, including Morocco, the Democratic Republic of Congo, Canada, the United States, the United Kingdom, and Germany.
Launch feedback:

#### Post-Launch Results - First Month
The new mobile app saw strong user engagement in its first month. **Over 2,000 installs** across Android and iOS platforms.
###### Subscription Breakdown
- Monthly subscriptions: approximately **60% of users** opted for a **monthly subscription**, with the majority starting with a free trial.
- Annual subscriptions: approximately **30% of users** chose an **annual plan**, reflecting strong trust and lasting commitment.
- Mid-term subscriptions (6 months): approximately **10% of users** preferred this **intermediate commitment**.
###### Platform-Specific Insights
This subscription distribution pattern highlights **the success of the onboarding and subscription strategy,** indicating that the UX effectively communicated the product's value and encouraged long-term engagement.
Reviews found on AppStore / Google Play / Trustpilot:





## Final Thoughts
Based on the data collected, we believe we have successfully designed **an effective application.** It integrates principles of cognitive psychology. It also offers user-friendly and engaging UX interactions. By combining intuitive navigation with interactive learning elements, it delivers a personalized user experience. Thanks to this, our app fosters **regular practice and lasting motivation.** It also enables significant progress in English learning for French-speaking learners.
You can check out **the interactive Figma prototype here** → [LINK](https://www.figma.com/proto/OfWcem6ytSSSAvaeP9nnOv/%F0%9F%91%A9%F0%9F%8F%BB%E2%80%8D%F0%9F%8F%AB-Lea-English?page-id=1453%3A591&node-id=1562-4425&p=f&viewport=226%2C167%2C0.05&t=8uDnG5QbLEdpTfjn-9&scaling=scale-down&content-scaling=fixed&starting-point-node-id=1562%3A4425&show-proto-sidebar=1)
---
### Easily Manage Your Website Content with Outstatic
URL: https://www.bearstudio.fr/en/blog/posts/easily-manage-your-website-content-with-outstatic
Date: 2025-04-25
A while back, I worked on a landing page with a blog section. Two major constraints came up:
- Easily integrate this section into an existing Next.js project,
- Allow anyone to add articles without writing a single line of code.
After several rounds of research and testing, I ultimately chose the [Outstatic](https://outstatic.com/) library.
## What is Outstatic?
Outstatic is an open-source CMS (Content Management System) designed for developers using Next.js. But unlike traditional CMS platforms like WordPress, it has several interesting features:
- **No database:** Outstatic works solely with Markdown files saved in your GitHub repository. No need to manage a database — everything is simple and fast.
- **Hosted directly in the project:** Outstatic integrates directly into your Next.js project. No external service or separate deployment needed.
- **Intuitive user interface:** Once configured, anyone (even without technical knowledge) can create articles or pages through an admin interface.
## Pros and Cons
Before showing you the library in action, here are what I consider to be some pros and cons of this library compared to more traditional CMS solutions.
### Pros
- Simplicity and speed: In just a few minutes, you get a functional blog.
- Self-hosted: Everything stays in your project, no external dependencies.
- Draft management: Flexible enough to publish your articles at the right time.
- No database: Perfect for static projects.
### Cons
- GitHub dependency: Outstatic requires a GitHub connection, so every contributor must have an account and be added to the organization. It's not possible to use Outstatic with other version control solutions. Additionally, this can be problematic in some companies for non-technical team members.
- Complex collaboration: If you're working with an organization, this requires an OAuth configuration.
- Not suitable for large data volumes: When article files stored in your Git repository become too numerous, it can lead to decreased performance on your site.
## How to Configure Outstatic?
Setting up Outstatic on your project is very simple — it only takes 3 steps:
### Step 1: Install Outstatic
Add Outstatic to your project by running:
```bash
npm install outstatic
```
### Step 2: Create an OAuth App on GitHub
Outstatic uses GitHub for authentication and article management. Here's how to create an OAuth app:
1. Go to [GitHub Developer Settings](https://github.com/settings/developers).
2. Click on New OAuth App.
3. Fill in the fields:
- Application name
- Homepage URL: Your site's URL (for example, `http://localhost:3000` locally).
- Authorization callback URL: Add `/api/auth/callback/github` to your URL (for example, `http://localhost:3000/api/auth/callback/github`).
4. Once the app is created, note your client ID and client secret.

### Step 3: Integrate Outstatic into Your Project:
1. Create a .env file with the previously retrieved variables.
```bash
OST_GITHUB_ID=YOUR_GITHUB_OAUTH_APP_ID
OST_GITHUB_SECRET=YOUR_GITHUB_OAUTH_APP_SECRET
# OST_REPO_SLUG
# The name of your repository on GitHub without the username
OST_REPO_SLUG=YOUR_GITHUB_REPOSITORY_SLUG
# OPTIONAL
# If empty this will default to your GitHub username
OST_REPO_OWNER=YOUR_GITHUB_USERNAME
# OPTIONAL
# If empty this will default to main
OST_REPO_BRANCH=YOUR_GITHUB_REPOSITORY_BRANCH
```
2. By following the [official Outstatic documentation](https://outstatic.com/docs/getting-started#adding-outstatic-to-a-nextjs-website), it will be very easy to configure the remaining elements: layout, admin page, and API.
## How to Add Content?
### Creating a Collection
From the interface, you can create a collection: for example, for a blog you would create an "Articles" collection that will contain all your articles. By default, each collection item has a title, description, image, author, etc., but you can also create custom fields. Once the article is created, it is saved in your GitHub repository as a Markdown file in the defined folder (content by default).

### Viewing and Retrieving Articles:
To retrieve your Markdown articles, use the methods provided by Outstatic: `getDocuments` or `getDocumentBySlug`. Then convert the content to HTML to style it.
```javascript
const posts = getDocuments('articles', ['title', 'slug']);
const post = getDocumentBySlug('articles', slug, [
'title',
'publishedAt',
'slug',
'author',
'content',
'coverImage',
]);
```
## How to Style the Article?
In my case, I chose to use Tailwind CSS and specifically [Tailwind Typography](https://github.com/tailwindlabs/tailwindcss-typography) to handle the styling of Markdown articles: you can customize your articles as you wish, by modifying the style of headings, images, etc.
```jsx
{data.title}
Published on {data.date} by {data.author}
{content}
```
## Writing an Article with Outstatic VS the Result on the Site
When you write an article on the admin interface, the style is not the same as on the page where you'll display the article for your users. Here for example is the Outstatic interface in the first image — this is where you write the article, fill in its title, description, etc. In the second image, I've added styling and used the "title", "author", and "cover image" properties to create the article header.


## My Opinion on Outstatic
In the past, I've had the opportunity to use WordPress for several projects, whether in a professional, personal, or academic context. While this tool remains a reference for creating websites and blogs, it does impose certain constraints in terms of customization. Generally, you choose a predefined theme to structure the display of articles, which limits flexibility and integration within a more complex project.
With Outstatic, the approach is quite different. This tool offers fully customizable content management, allowing you not only to structure articles according to your own needs but also to integrate it directly into an existing website. It thus becomes possible to benefit from a lightweight and modular content management solution without having to depend on a heavy ecosystem like WordPress.
In conclusion, [Outstatic](https://outstatic.com/) is a simple and effective solution for adding a blog section to a Next.js site. It's a perfect tool for projects where content management needs to be fast and accessible, without sacrificing control over the code.
Author: [Jeanne Grenet](https://www.linkedin.com/in/jeanne-grenet)
---
### Start UI
URL: https://www.bearstudio.fr/en/blog/posts/start-ui-opinionated-ui-starter
Date: 2021-11-01
When using User Interface (UI) starters in the past, we found ourselves faced with deciding which technology would be best for us to use. From UI framework, HTTP Client, Routing Library, Style Library, Form Library, to downloading all the configurations and dependencies needed can be very time consuming. To put everything in one place and streamline how we choose these options, we decided to dive into creating our own User Interface Starter called **_Start UI_**_._
## What is Start UI?
🚀 Start UI is a collection of opinionated UI starters for design, web and mobile (mostly React based at the moment) which lets you easily bootstrap new UI projects. Based on our many years of experience working with starters and on real projects ranging from small to large scale applications, 🚀 Start UI starters are opinionated and made of strong architectural design decisions. They come with many configurations (such as Internationalization, API Mocking, [Storybook](/en/services), Dark Theme…), components and user administration interfaces by default. Those features help to avoid the setup phase and quickly develop the features specific to the project use cases.
At the moment, 🚀 Start UI is made of 3 projects: 🚀 Start UI \[web\], 🚀 Start UI \[native\] and 🚀 Start UI \[figma\].
### 🚀 Start UI \[web\]
... is our most advanced starter that can be used for [SEO](/fr/blog/articles/checklist-seo-technique) (Search Engine Optimisation), PWA (Progressive Web Application), SPA (Single Page Application), SSR (Server Side Rendering). It is web ready and will boost your project setup and your productivity while ensuring code quality.
### 🚀 Start UI \[native\]
... is used to develop mobile applications. Based on React Native with quite a different stack, this starter helps you to quickly push your application to the Stores.
### 🚀 Start UI \[figma\]
... is a Figma file that represents what is possible to do with 🚀 Start UI \[web\] and 🚀 Start UI \[native\]. It is made of components (auto layout, variants, etc) that are available to the developer in the Web and Native version, so your designers are always doing interfaces that are possible for the developer to implement.
At BearStudio, we maintain and use all 3 of these starters, and our clients are pleased that we come with a solution to quickly bootstrap their projects. All developers that are comfortable with React can start using 🚀 Start UI \[web\] and 🚀 Start UI \[native\] for their projects, and designers that are comfortable with Figma can start using 🚀 Start UI \[figma\]. The benefits for the \[web\] and \[native\] versions are: **productivity** because you will skip the setup phase, **code quality** using the ESLint and Prettier configuration, **code safety** using TypeScript and tests configuration. For 🚀 Start UI \[figma\], the main benefit is **productivity** because it comes with a lot of components that are available in the \[web\] and \[native\] versions.
**Start using 🚀 Start UI \[web\] today using the command line we developed:**
`npx create-start-ui --web myApp`
([https://github.com/BearStudio/start-ui-web](https://github.com/BearStudio/start-ui-web))
**Start using 🚀 Start UI \[native\] today using the command line we developed:**
`npx create-start-ui --native myApp`
([https://github.com/BearStudio/start-ui-native](https://github.com/BearStudio/start-ui-native))
**Start using 🚀 Start UI \[figma\] today from Figma community**
([https://go.bearstudio.fr/start-ui-figma](https://go.bearstudio.fr/start-ui-figma))
---