La curiosité, un état d'esprit !

Qu’est-ce qu’être curieux quand on est développeur ?

La curiosité, dans le métier de développeur, ce n’est pas simplement lire des articles ou suivre des comptes tech sur les réseaux sociaux. C’est une posture active : chercher à comprendre le "pourquoi" derrière chaque choix technique, pas seulement le "comment".

Un développeur curieux ne se contente pas de faire fonctionner son code. Il se demande pourquoi une architecture hexagonale est plus adaptée qu’un MVC classique dans tel contexte. Il explore un langage fonctionnel non pas parce que c’est à la mode, mais parce qu’il pressent que cela changera sa façon de modéliser les problèmes.

La curiosité, c’est aussi accepter de ne pas savoir — et considérer cette zone d’inconfort comme un terrain de jeu plutôt qu’un obstacle. C’est le moteur qui transforme un exécutant en artisan du logiciel.

Chez DevToBeCurious, nous croyons que cette posture est la compétence la plus différenciante en 2026 : les outils changent, les frameworks passent, mais la capacité à apprendre, questionner et s’adapter reste.

De la curiosité au résultat : exemples concrets

La curiosité n’est pas abstraite. Elle produit des résultats mesurables. Voici des parcours que nous observons régulièrement dans nos accompagnements :

Découvrir le TDD par curiosité, livrer plus vite par conséquence

Un développeur backend, habitué à écrire ses tests après le code, décide d’essayer le Test-Driven Development sur un petit module. Résultat : après deux sprints, le nombre de bugs en recette chute de 40 %. L’équipe adopte la pratique. Ce n’est pas une directive managériale qui a produit ce changement — c’est la curiosité d’un développeur qui a osé essayer autrement.

Explorer un nouveau langage pour résoudre un problème existant

Une développeuse C# commence à s’intéresser à Rust le week-end. Elle n’a pas l’intention de réécrire son backend, mais la rigueur du compilateur Rust change sa façon de penser la gestion mémoire et les erreurs. De retour sur son projet .NET, elle refactorise un service critique avec des patterns inspirés de Rust (Result types, ownership clair). Les incidents en production sur ce service passent de deux par mois à zéro.

Tester l’IA générative au-delà du buzz

Un lead dev, sceptique sur les LLMs, décide de tester Claude Code en conditions réelles sur un sprint. Plutôt que de l’utiliser comme un simple auto-complétion, il explore l’agenting : revue de code automatisée, génération de tests, refactoring assisté. En trois semaines, il identifie les cas où l’outil accélère réellement le travail (scaffolding, tests unitaires) et ceux où il faut garder la main (architecture, décisions métier). Son équipe gagne un cadre pragmatique d’utilisation de l’IA, sans hype ni rejet.

Curiosité et performance d’équipe : l’angle CTO et lead technique

En tant que CTO ou lead technique, vous le savez : une équipe qui n’apprend plus stagne, puis régresse. La curiosité individuelle est importante, mais c’est la curiosité collective qui crée un avantage compétitif durable.

Les équipes les plus performantes partagent un trait commun : elles cultivent un environnement où poser des questions est valorisé, où expérimenter est encouragé, et où l’échec d’une exploration est considéré comme un apprentissage, pas comme une perte de temps.

Concrètement, cela se traduit par :

• Des tech radars vivants — pas un document figé, mais des sessions régulières où chaque membre présente une découverte, un outil, un pattern qu’il a testé.
• Du temps sanctuarisé pour l’exploration — 10 à 20 % du temps d’un sprint consacré à l’apprentissage produit un retour sur investissement mesurable en qualité de code et en rétention des talents.
• Le pair programming comme vecteur de curiosité — associer un développeur senior curieux avec un junior ne transmet pas que du savoir-faire, cela transmet une façon de penser.
• Des rétrospectives orientées apprentissage — au-delà de "qu’est-ce qui a bien/mal marché", demander "qu’avons-nous appris de nouveau cette semaine ?"

Le rôle du CTO n’est pas de forcer la curiosité, mais de créer les conditions pour qu’elle s’exprime. C’est un investissement stratégique, pas un luxe.

Curiosité active vs. veille passive : le point de vue d’Evan

Après plus de 20 ans dans le développement logiciel — en tant que développeur, lead technique, CTO et aujourd’hui formateur — Evan a observé une distinction fondamentale entre deux postures :

La veille passive, c’est scroller son feed Twitter/X, lire des titres d’articles, regarder passer les annonces de nouveaux frameworks. On a l’impression de "rester à jour", mais en réalité, on accumule du bruit sans profondeur. C’est confortable, mais ça ne change ni votre code, ni votre façon de penser.

La curiosité active, c’est l’opposé : c’est choisir un sujet, s’y plonger les mains dans le code, se confronter aux erreurs, et en tirer un apprentissage incarné. Ce n’est pas consommer de l’information — c’est produire de la compréhension.

La différence est concrète : un développeur en veille passive saura citer dix frameworks JavaScript sortis cette année. Un développeur en curiosité active en aura testé deux, compris les compromis de chacun, et sera capable de recommander le bon outil pour un contexte précis.

C’est cette conviction qui est au cœur de DevToBeCurious : la curiosité ne se consomme pas, elle se pratique. Nos formations et accompagnements sont conçus pour transformer la veille en action, l’information en compétence, et l’intérêt en expertise.

Se remettre en question au quotidien

Toujours pousser la nouveauté, pour découvrir des nouveaux chemins, des nouvelles façons de faire.

Apprendre un nouveau langage, s’aider des LLMs pour coder plus vite, s’appuyer sur Amazon Q, ou bien Github Copilot, ou encore Claude Code pour aller plus loin avec l’agenting.

Se remettre en question, c’est aussi découvrir de nouvelles façons de coder : fonctionnelle, réactive, déclarative. C’est penser en TDD, explorer l’architecture hexagonale avec TypeScript, Angular, ou React.

Retrouver le fun dans notre métier

Comment s’épanouir dans notre métier de développeur ?

Et si l’une des clefs était justement la curiosité ? Recréer cette envie de découvrir un nouveau langage, une nouvelle façon de coder, un nouvel outil qui change la donne ?

Le fun, c’est aussi retrouver l’envie de coder, même à l’ère des LLMs et des agents IA. Ces outils ne remplacent pas le plaisir de créer — ils l’amplifient quand on sait les utiliser avec curiosité.

En entreprise, c’est permettre aux développeurs et développeuses la possibilité de se former, de tester, d’apprendre, de prendre le temps nécessaire pour laisser la curiosité s’épanouir.

Dev to be Curious est là pour vous : catalyseur de votre curiosité, à Nantes et partout en France.