Le syndrome de l’objet brillant fait perdre du temps et de l’énergie à votre équipe. Voici comment y remédier.

Tout a commencé avec un lancement étincelant. Google venait tout juste de dévoiler les fonctionnalités multimodales de Gemini – une technologie qui semblait suffisamment prometteuse pour potentiellement résoudre les problèmes d'interaction entre humains et navigateur. L’équipe d’ingénierie pensait qu’il s’agirait d’une expérience rapide et peu risquée.

Une équipe a essayé. Puis une autre. Puis une troisième.

Mais si le concept était enthousiasmant, l’outil en lui-même n’était pas encore à la hauteur. Il s’agissait d’une version préliminaire, pas prête pour la production, et certainement pas adaptée au cas d’usage de l’équipe.

« Cela a été une distraction qui aurait pu facilement faire dérailler l’avancée sur les priorités existantes si nous n’avions pas freiné à temps, » se souvient Anand Sainath, responsable de l’ingénierie et cofondateur de 100x, qui a pris la décision d’arrêter l’intégration.

D’autres n’ont pas eu cette chance. Pour de nombreuses équipes, la course à la « prochaine grande innovation » a peu à peu détourné le plan de développement produit. Il ne restait alors qu’un patchwork d’outils inachevés et de priorités manquées – ce que Sainath appelle le coût caché du syndrome de l’objet brillant.

C’est quoi au juste le syndrome de l’objet brillant ?

Le syndrome de l’objet brillant (SOS) survient lorsque les équipes se laissent distraire par de nouveaux outils, frameworks ou technologies, souvent au détriment des priorités en cours. 

« Lorsqu’une nouvelle technologie arrive, comme c’est le cas pour l’IA aujourd’hui, le marché s’enthousiasme pour ses applications. Il peut y avoir une pression à suivre la tendance pour rester compétitif, » explique Raju Malhotra, CPTO chez Certinia.

C’est alors que l’outil ou le framework « brillant » s’intègre dans vos projets et « détourne l’ingénierie du travail qui compte réellement aujourd’hui pour les clients. »

L’histoire d’Evernote coche toutes les cases du bingo du syndrome de l’objet brillant. Il y avait tous les bons ingrédients : une base d’utilisateurs fidèles, un produit solide et une niche clairement identifiée. Mais au lieu de consolider ses fonctionnalités phares, l’entreprise s’est tournée vers des produits physiques et a lancé des fonctionnalités mal finalisées comme Work Chat. 

Le produit est devenu surchargé, les performances ont chuté et les utilisateurs sont partis vers des outils plus simples comme Notion et Google Keep. En 2022, Evernote fut racheté, et début 2023, la plupart des salariés ont été licenciés. 

Le SOS ne mène pas toujours à la faillite ou à des licenciements, mais il ralentit presque systématiquement la dynamique de l’équipe en :

• Retardant les livraisons de projet : Renoncer fréquemment à ses choix technologiques en cours de projet perturbe la planification, entrave les cycles d’exécution et introduit de l’inflation de périmètre non prévue. C’est précisément ce qui s’est produit pour le projet Virtual Case File du FBI. Après cinq ans et 170 millions de dollars investis, le projet a été abandonné, en partie parce que le réalignement bureaucratique-entreprise cassait sans cesse le rythme de livraison.
• Augmentant les coûts d’ingénierie : Sans cadre pour évaluer les nouvelles technologies, les décisions dictées par le syndrome de l’objet brillant se traduisent souvent par une inflation d’outils, de la dette technique et des coûts élevés de développement logiciel. Les équipes perdent même du temps sur des prototypes qui ne voient jamais le jour, ou pire, qui sont mis en production puis réécrits.
• Saccageant la productivité des développeurs : Chaque nouvel outil implique une nouvelle courbe d’apprentissage, plus de bugs, et davantage de « tests rapides » qui ne le restent jamais. Cela épuise les ingénieurs, réduit la productivité jusqu’à 40 %, et mène à de la fatigue ou à une gestion permanente de crises – de l’énergie qui aurait pu être investie dans le développement de fonctionnalités clés.
• Érodant la confiance des parties prenantes : Le SOS envoie également le mauvais signal aux dirigeants. Quand les priorités changent trop souvent et que les délais sont dépassés, la direction peut commencer à douter de la capacité de l’ingénierie à livrer. Une fois la confiance perdue, il est difficile de la regagner.

Évitez le syndrome de l’objet brillant : 3 questions pour faire le tri en équipe

Vous connaissez désormais les ravages que peut causer le syndrome de l’objet brillant sur votre équipe. Mais comment déterminer si une nouvelle librairie, un SDK ou un service vaut le coup – avant qu’il ne vampirise votre temps et vos ressources ? Nos experts conseillent de procéder à quelques vérifications :

1. Est-ce un « wrapper » ou un « pansement » ?

Le filtre de Sainath face aux nouveaux outils ou technologies flashy est simple : Est-ce que cela répond à un besoin pérenne ou n’est-ce qu’un simple pansement ?

« Un pansement ne fait que masquer les cas limites mineurs ou des restrictions à court terme. Mais il y a fort à parier que la prochaine version du modèle résoudra ce problème. Ce que vous avez construit devient alors aussitôt obsolète. »

Il préfère se concentrer sur la création de "wrappers" : des couches propres au-dessus des modèles de base, qui ajoutent une véritable utilisabilité grâce au design, aux flux de travail, ou au contexte.

« Le terme LLM wrapper a été utilisé presque de façon péjorative au début, mais fondamentalement, beaucoup de produits de valeur sont construits sur une technologie sous-jacente, » commente Sainath. « Regardez Cursor. On pourrait dire que ce n’est qu’un wrapper, mais il apporte une valeur significative et ciblée. »

De son point de vue, les solutions de fortune ne sont que des distractions qui peuvent facilement devenir de nouveaux jouets brillants. Les wrappers bien conçus, en revanche, peuvent devenir des produits essentiels.

2. Que choisissons-nous de ne pas construire ?

Selon Malhotra, suivre ce que l’équipe choisit de ne pas développer est tout aussi important que ce qui intègre la feuille de route. « Cela nous empêche de courir après des fonctionnalités qui pourraient bien paraître en démo mais qui n’améliorent pas réellement le quotidien, » explique-t-il.

Même lorsque l’équipe n’est pas convaincue qu’une solution est prête pour un déploiement plus large, elle la teste quand même avec des premiers utilisateurs. « Cela nous permet d’obtenir des retours sans perturber la feuille de route. »

3. Quelle est la valeur business ?

Pour le VP Engineering de Customer.io, Paul Senechko, comprendre la valeur commerciale derrière les efforts d’ingénierie est le premier et le plus essentiel des filtres. Si un nouvel outil ou système ne sert pas ce but, dit-il, ce n’est probablement pas le bon moment pour l’adopter.

« Le principe de leadership de notre entreprise, c’est que nous sommes les experts des clients, » explique Senechko. « Nous utilisons ce principe pour guider nos investissements technologiques, afin de nous assurer que ce que l’on construit est pensé pour le client et pour l’entreprise. »

Pour permettre à son équipe de garder les pieds sur terre, Senechko s’appuie sur quelques questions simples mais percutantes : Quel est le coût en termes de temps et de ressources ? Est-ce que cela améliore notre produit ? Cela aidera-t-il nos clients à être plus performants ?

Sainath ajoute sa propre perspective, avec ce qu’il appelle les questions « et si » : « Que se passerait-il si la technologie sous-jacente devenait 10 fois meilleure ? Est-ce que notre produit s’améliorerait automatiquement, ou deviendrait-il tout d’un coup obsolète ? »

Il interroge également l’effort à fournir pour bénéficier de ces avancées : « Est-ce que nous profiterons automatiquement de ces progrès, ou faudra-t-il une refonte majeure pour rester à niveau ? »

Tester ces scénarios avec votre équipe peut vous aider à choisir : faut-il vraiment privilégier cette nouvelle pile technologique, ou bien continuer avec ce qui fonctionne déjà ?

Comment sécuriser votre feuille de route contre le syndrome du shiny object (sans tuer l’innovation) 

Lorsque de nouvelles technologies enthousiasmantes surgissent, il faut prendre du recul et équilibrer l’innovation avec de réelles avancées.

Voici comment les CTO gèrent la peur de manquer l’opportunité et gardent leur équipe concentrée et ancrée :

1. Définir des critères de sortie avant de démarrer les projets

Beaucoup d’expérimentations technologiques dites « exploratoires » se transforment en projets parallèles qui s’éternisent, à la portée floue et générant de la dette technique, simplement parce que personne ne définit comment ou quand elles doivent se terminer. S’il n’y a ni responsable, ni échéance, ni critères de succès, il est inévitable que le syndrome du shiny object fasse tout dérailler. Pour l’éviter, traitez chaque test technologique comme une nouvelle fonctionnalité produit : délimitée, à durée fixée, pilotée, et issue d’un cas d’usage concret.

Comme le dit Senechko : « Commencez par de petits cas d’usage réels, puis élargissez au besoin. Dès lors que nous décidons de tester une nouvelle tendance, nous nous assurons d’identifier un endroit limité et précis où tester et vérifier que cela fonctionne. Ainsi, nous pouvons expérimenter et acquérir une vraie expérience sur la technologie avant de miser gros dessus. »

Impliquez un relecteur transverse (EM + PM + ingénieur staff) pour une évaluation objective, et élaborez un calendrier structuré incluant :

• Durée maximale : Limitez à 2 sprints (+1 tampon) pour rester concis et testable
• Jalons Go/No-Go avec conditions de sortie : Définissez un moment d’évaluation explicite où l’équipe décide de continuer, d’itérer ou d’arrêter (plus de 10 % des builds échoués, ou absence d’intégration à l’outil CI/CD, par exemple).

Senechko suggère même aux équipes d’expérimenter des initiatives à durée fixe mais à périmètre variable, en fixant au départ une « appétence » pour le temps à allouer, dans le but de livrer le résultat le plus utile dans ce laps de temps. « Cela nous permet d’innover et d’échouer rapidement quand il s’avère que ces nouvelles pistes ne sont pas prometteuses. »

2. Utiliser des métriques pour mesurer le succès

Une fois la faisabilité technique et la charge de travail d’ingénierie comprises, définissez ce à quoi ressemble la réussite. C’est la frontière entre un déploiement discipliné et un projet SOS victime d’une dérive de périmètre. Élaborez un cadre qui mesure le succès selon plusieurs dimensions :

• Personnes : Gain de productivité pour les développeurs, augmentation des heures de travail approfondi
• Processus et flux de travail : Temps d’exécution des tests réduit, baisse des taux de régression, flux de déploiement plus rationalisés, réduction du délai de mise sur le marché
• Expérience client : Meilleure performance des pages, moins de plaintes UX, temps de réponse améliorés
• Performance du système : Calcul plus rapide, coûts d’infrastructure plus bas, moins d’incidents ou de retours en arrière

3. Connaissez vos clients

« Rester sur la bonne voie dépend de l’honnêteté sur la provenance réelle de la valeur pour le client, » affirme Malhotra. « Les tendances peuvent sembler excitantes, mais elles deviennent vite des distractions si elles n’aident pas directement les clients à accomplir leur travail mieux ou plus rapidement. »

Ce principe se retrouve dans la façon dont de nombreuses équipes associent aujourd’hui produit, ingénierie et service client pour des sessions de shadowing en direct. Quelques ingénieurs participent à des appels de support, séances d’onboarding ou points réguliers avec le client afin de recevoir des retours réels, sans filtre. Entendre de première main ce qui trouble les utilisateurs, ce qui casse et ce qui est salué développe l’empathie et peut même affiner la priorisation dans les équipes d’ingénierie. 

Mais écouter ne suffit pas. Pour identifier les réelles difficultés des clients, complétez le feedback qualitatif par des données de télémétrie produit. Il y a fort à parier que votre outil d’analyse (PostHog, Amplitude, Heap) est sous-exploité à cette fin. Commencez à suivre comment les utilisateurs interagissent vraiment avec le produit : clics, actions, boucles de navigation, parcours et erreurs. 

Associez ces données comportementales aux tickets d’assistance pour repérer les schémas. Une fonctionnalité est-elle ignorée parce qu’on ne la trouve pas facilement ? Des utilisateurs n’arrivent-ils pas à accomplir des tâches critiques ? Utilisez-les comme déclencheurs pertinents pour des projets pilotes axés client.

Avec le temps, vous constituerez naturellement un « répertoire de la voix du client » rassemblant leurs points de douleur, retours, sources de satisfaction et blocages récurrents, qui alimenteront les décisions produit et ingénierie depuis les équipes service client. 

C’est ce même système qu’a utilisé l’équipe de Senechko pour prioriser le travail selon la valeur client mesurable : « Un important volume de clients et des exigences de faible latence ont poussé notre équipe à inventer des solutions qu’aucune méthode du marché ne pouvait réaliser. Investir dans notre plateforme technique fait partie de l’ADN de l’entreprise, car nous en avons vu les bénéfices aussi bien pour les clients que pour le business. »

In fine, le vrai progrès pour l’ingénierie proviendra de la conception de nouvelles capacités qui étendent ce qui fonctionne déjà, et non en contournant ou en ajoutant quelque chose de totalement nouveau. Voilà comment les équipes évoluent sans briser les systèmes éprouvés.

« L’innovation n’est pas forcément synonyme de rupture. Elle doit renforcer ce qui fonctionne et permettre aux clients d’avancer plus vite avec moins d’efforts, » résume simplement Malhotra.

Envie de lire d’autres conseils comme celui-ci ? Abonnez-vous à la newsletter The CTO Club.