Si vous avez apprécié notre premier article sur Android Makers, et bien en voici un deuxième ;-)

Les pièges classiques dans les équipes tech (et comment les éviter)

par Renaud Mathieu

Ce sujet revient souvent : que ce soit dans le choix des outils, des process, ou dans la culture d’entreprise, on a tous déjà croisé ces travers. Pour les explorer de façon un peu originale, Renaud va les passer en revue à travers le prisme des sept péchés capitaux.

1. L’orgueil – ou le syndrome du “moi je sais”

C’est le fameux piège de l’over-engineering : vouloir trop bien faire, trop tôt, en adoptant systématiquement les dernières nouveautés, comme si tout ce qui sortait devait forcément être intégré. C’est souvent porté par l’idée que cela va servir plus tard pour une autre fonctionnalité ou un dimensionné pour un futur besoin. Cela pose aussi la question de la qualité… qui dépend en réalité du point de vue : dev, product, client, etc.

Comment l’éviter ? Revenir à des fondamentaux solides comme :

• KISS (Keep It Simple, Stupid)
• YAGNI (You Aren’t Gonna Need It)
• Les principes SOLID

2. L’avarice – tout vouloir, tout de suite

Backlog interminable, DOR/DOD ignorés, tickets en WIP qui s’accumulent sans avancer… Bref, l’envie de tout faire à la fois finit par paralyser l’équipe.

Quelques antidotes efficaces :

• Red Bin (blocked) : une colonne pour identifier les problèmes à résoudre en priorité
• One Piece Flow : traiter un sujet à la fois pour éviter le multitâche et le “context switching”
• Heijunka : lisser le flux de travail, déclencher un livrable régulièrement afin en quelque sorte de “flusher” les tickets “done” 
• MoSCoW : prioriser selon Must/Should/Could/Won’t
• Mesurer l’impact : base-toi sur les analytics, le nombre d’utilisateurs impactés, “know your users” etc.

3. La luxure – la tentation des technos trop sexy

Envie irrésistible d’intégrer la dernière techno hype… même si ce n’est pas le bon moment. Résultat : instabilité, dette technique, perte de temps.

Solution ? → Utilise des outils comme Gradle pour analyser tes dépendances, mesurer les temps de build, et t'assurer que chaque ajout est réellement utile.

4. L’envie – se comparer aux autres

Regarder ce que font les autres équipes, jalouser leur rythme ou leurs outils, sans tenir compte de son propre contexte, peut vite démoraliser.

Pour y remédier :

• Apprends à te connaître en centralisant ta doc (Single Source of Truth)
• Suis tes metrics internes :
  • Fréquence de déploiement
  • Lead time (To Do → Done)
  • Taux de bugs, échecs de déploiement, etc.

5. La gourmandise – l'automatisation à l’excès

Tout automatiser, à tout prix, sans réfléchir à la réelle valeur ajoutée. Parfois, un peu de manuel fait gagner plus de temps qu’un script bancal.

6. La colère – quand la tension monte sur GIT

Les désaccords techniques ou les non-dits explosent parfois pendant les code reviews, créant un climat toxique.

Comment apaiser ?

• Partager la connaissance
• Suivre les conventions d’équipe et donc commencer par les écrire et les partager
• Favoriser le pair programming et le remote screen sharing

7. La paresse – remettre à plus tard les bonnes pratiques

Pas ou peu de tests unitaires, décisions repoussées, legacy important, backlog laissé en plan… Autant d’indicateurs d’une fatigue technique.

La solution : → Adopter un workflow de type PDCA (Plan, Do, Check, Act) → Insuffler une culture de l’amélioration continue (Kaizen)

Conclusion

Les pièges sont nombreux, mais souvent évitables avec un peu de lucidité, de priorisation, et surtout, une culture d’équipe saine et bienveillante. À travers quelques exemples bien choisis, Renaud nous redonne des clés qu’on connaît mais qu’on a parfois du mal à pousser lorsqu’on a tous la tête dans le guidon.

The State of Voice Interactions on Android

par Elaine Dias Batista

Introduction

Dans cette conférence, Elaine Dias Batista nous présente l'état actuel des interactions vocales sur Android. Sa présentation couvre plusieurs aspects essentiels : pourquoi intégrer des interactions vocales dans une application mobile, quelles sont les étapes nécessaires pour les mettre en œuvre, et comment les développeurs peuvent réaliser cette intégration. Elle conclut avec des réflexions pertinentes sur l'avenir de cette technologie.

Pourquoi intégrer des interactions vocales ?

L'intégration d'interactions vocales dans une application mobile présente plusieurs avantages majeurs :

• Utilisation sans les mains : Elle permet aux utilisateurs d'interagir avec l'application sans avoir besoin d'utiliser leurs mains, offrant ainsi une expérience plus fluide dans certaines situations (conduite, cuisine, sport).
• Accessibilité améliorée : Elle rend les applications plus accessibles aux personnes en situation de handicap, notamment celles ayant des difficultés motrices.
• Expériences innovantes : Elle ouvre la porte à de nombreuses possibilités créatives et à des expériences utilisateur novatrices qui peuvent différencier votre application sur un marché concurrentiel.

Les composants essentiels d'une interaction vocale

Pour mettre en place des interactions vocales efficaces, plusieurs éléments techniques sont à considérer :

1. Détection du mot d'éveil (Wake word detection) : Permet à l'application de commencer à écouter lorsqu'un mot ou une phrase spécifique est prononcé.
2. Reconnaissance vocale (STT - Speech-to-Text) : Convertit l'audio de la commande vocale en texte exploitable.
3. Traitement du langage naturel (NLP - Natural Language Processing) : Analyse du texte pour en extraire l'intention de l'utilisateur.
4. Logique métier : Exécute l'action correspondant à l'intention identifiée.
5. Synthèse vocale (TTS - Text-to-Speech) : Convertit la réponse textuelle en discours pour répondre vocalement à l'utilisateur.

Il existe également des fonctionnalités secondaires qui peuvent enrichir l'expérience :

• Diarisation des locuteurs : Identification des différents interlocuteurs dans une conversation.
• Gestion des interruptions : Capacité à adapter la réponse lorsque l'utilisateur interrompt l'assistant vocal.

Il est important de noter qu'il n'est pas nécessaire d'implémenter toutes ces étapes. Le choix dépend des besoins spécifiques de votre application.

Comment implémenter les interactions vocales ?

Avant de voir les différentes manières d’implémenter les interactions vocales, nous avons eu la timeline Android des librairies pour les interactions vocales.

1. Intégration avec une plateforme vocale existante

2. Intégration dans une application existante

Cette approche peut utiliser des API propriétaires ou tierces selon les besoins et les contraintes du projet.

Solutions proposées par Google

Pour intégrer Google Assistant à votre application :

• App Actions : Cette fonctionnalité permet à votre application d'étendre les capacités de Google Assistant. Pour l'utiliser, vous devez inclure un fichier shortcuts.xml dans votre application, qui définit les intents disponibles pour les interactions vocales. Ces intents permettent à Google Assistant de comprendre et d'exécuter les commandes vocales destinées à votre application.
• Actions on Google : Permet de gérer les interactions entre l'Assistant, l'application et Android, offrant une expérience utilisateur fluide.

🚨Il est important de noter que Google Assistant est progressivement remplacé par Gemini, et qu'il n'est pas possible d'avoir les deux installés simultanément sur un appareil.

L'API Gemini + Google

L'API Gemini peut remplacer les étapes de STT et NLP en une seule solution. Sa dernière version supporte le traitement des vidéos, images, audios et textes. Cette API permet d'utiliser les capacités d'IA avancées de Google pour comprendre et traiter les commandes vocales.

D'autres projets intéressants sont à considérer :

• Gemma3
• MediaPipe (compatible avec iOS et Web)
• Voice Access (fonctionnalité d'accessibilité)
• DialogFlow pour transformer le texte en intention

Solutions tierces

De nombreuses alternatives existent sur le marché :

Développement interne

Pour les équipes souhaitant développer leurs propres solutions :

• Modèles sur Hugging Face : Plateforme proposant de nombreux modèles prêts à l'emploi pour diverses tâches liées au traitement vocal.
• LLM locaux : Possibilité d'intégrer des modèles de langage plus légers directement dans l'application.

Cas d'utilisation intéressants

Parmi les cas d'utilisation prometteurs mentionnés lors de la conférence :

• Apprentissage des langues : Utilisation de petits modèles (environ 100 mots) pour faciliter l'apprentissage linguistique.
• Applications sensibles à la confidentialité : Traitement vocal hors ligne pour éviter la fuite de données personnelles.
• Accessibilité : Applications permettant aux personnes à mobilité réduite d'utiliser leur téléphone via la voix.

Réflexions finales

Plusieurs points importants sont à retenir :

• Approche sélective : Il n'est pas nécessaire d'implémenter toutes les fonctionnalités d'interaction vocale. Concentrez-vous sur celles qui apportent une réelle valeur à votre application.
• Priorité au mode hors ligne : Pour des raisons de performance et de confidentialité, envisagez des solutions qui fonctionnent sans connexion internet.
• Protection des données : La confidentialité est une préoccupation majeure. L'utilisation de modèles locaux peut aider à prévenir les fuites d'informations sensibles.

Conclusion

Les interactions vocales représentent une opportunité majeure pour améliorer l'expérience utilisateur des applications Android. Avec la multitude de solutions disponibles, des API de Google aux plateformes tierces, en passant par les options open-source et hors ligne, les développeurs disposent aujourd'hui de tous les outils nécessaires pour intégrer cette technologie de manière adaptée à leurs besoins spécifiques.

L'avenir des interactions vocales s'annonce prometteur, avec des applications toujours plus naturelles, accessibles et respectueuses de la vie privée des utilisateurs. Les développeurs qui sauront tirer parti de ces technologies seront en mesure d'offrir des expériences utilisateur différenciantes et innovantes.

Building dynamic forms with JSONForms and Kotlin Multiplatform

par Gérard Paligot

Lors de l'édition 2025 d'Android Makers, Gérard Paligot nous présente les problématiques de la création de formulaires adaptatifs pour un public international. Lorsque les formulaires sont utilisés par de multiples entités commerciales ou dans différents pays, c’est souvent difficile de s’y retrouver correctement. Ces applications nécessitent souvent des formulaires complexes et hautement personnalisés, qui peuvent rapidement devenir difficiles à maintenir, incohérents et dépourvus d'une direction de conception claire. Les systèmes de conception existants ont souvent du mal à répondre à ces exigences, ce qui entraîne une mauvaise expérience utilisateur et des coûts de développement élevés.

L'approche déclarative basée sur JSONForms

Pour relever ces défis, Gérard Paligot a montré une approche déclarative innovante utilisant JSONForms. Cette approche permet de structurer les formulaires en trois blocs distincts mais interconnectés : le schéma de données (schema), l'interface utilisateur (UIschema) et l'état des données (state).

• Le schéma de données (schema): Ce bloc constitue la base du formulaire, définissant les propriétés essentielles de chaque champ, telles que le type de champ (texte, email, mot de passe, etc.) et les contraintes associées (longueur minimale/maximale, expressions régulières, etc.). Il garantit que les données collectées sont valides et conformes aux exigences de l'application, qu'il s'agisse d'un numéro de téléphone spécifique à un pays ou d'un code postal au format approprié.
• L'interface utilisateur (UIschema)  : Ce bloc dicte la présentation visuelle du formulaire. Il utilise des layouts verticaux et horizontaux, ainsi qu'une variété de contrôles (zones de texte, cases à cocher, boutons radio, sélecteurs de date, etc.) pour organiser les champs de manière intuitive et conviviale. Chaque élément est associé à un identifiant unique, ce qui facilite la manipulation et la personnalisation en fonction des besoins spécifiques de chaque marché ou entité commerciale. Par exemple, un champ "état/province" peut être rendu pertinent pour certains pays et masqué pour d'autres.
• L'état des données (state).: Ce bloc stocke dynamiquement les valeurs saisies par l'utilisateur dans le formulaire. Il permet de suivre les modifications en temps réel et d'appliquer des règles conditionnelles pour afficher ou masquer certains éléments en fonction des données saisies. Par exemple, un champ "numéro de sécurité sociale" peut apparaître conditionnellement en fonction du pays de résidence sélectionné par l'utilisateur.

// Exemple de schema
{
 "type":"object",
 "properties":{
   "name":{
     "type":"string"
   },
   "description":{
     "type":"string"
   },
   "done":{
     "type":"boolean"
   },
   "rating":{
     "type":"integer"
   }
 },
 "required":[
   "name"
 ]
}


// Exemple de UI Schema
{
 "type":"VerticalLayout",
 "elements":[
   {
     "type":"Control",
     "scope":"#/properties/name"
   },
   {
     "type":"Control",
     "scope":"#/properties/description",
     "options":{
       "multi":true
     }
   },
   {
     "type":"Control",
     "label":"Rating",
     "scope":"#/properties/rating"
   },
   {
     "type":"Control",
     "label":"Done?",
     "scope":"#/properties/done"
   }
 ]
}

Avantages de la séparation et personnalisation

Cette séparation claire entre la structure des données, la présentation et l'état des données offre de nombreux avantages. Elle favorise la modularité, la maintenabilité et la réutilisabilité des composants du formulaire, tout en permettant une personnalisation granulaire pour répondre aux nuances de chaque marché ou entité commerciale. Les développeurs peuvent facilement modifier le schéma de données pour s'adapter à de nouvelles exigences, ajuster l'interface utilisateur pour se conformer aux directives de la marque ou aux préférences locales, et implémenter une logique conditionnelle complexe dans l'état des données pour créer des formulaires vraiment adaptatifs et intelligents.

Renderers personnalisés et compatibilité multi-plateforme

Un temps fort de la conférence a été la démonstration de la création de renderers personnalisés. Gérard Paligot a montré comment les développeurs peuvent créer un renderer personnalisé de style Cupertino (iOS) pour une application Android, démontrant ainsi la flexibilité et l'adaptabilité de l'approche JSONForms. Il a également expliqué comment adapter les UI schemas pour assurer une compatibilité transparente entre les plateformes Apple et Android, en mettant en évidence les différences subtiles dans les layouts groupés et le comportement des contrôles.

Conclusion

En conclusion, le talk de Gérard Paligot a offert des insights précieux sur la création de formulaires adaptatifs pour des applications mobiles déployées dans des contextes internationaux et multi-BU. Son approche déclarative basée sur JSONForms repose sur une architecture claire, modulaire et standardisée, avec une séparation nette entre les données, la présentation et l’état. Cette structure permet à la fois une forte personnalisation via des renderers spécifiques et une grande adaptabilité aux contraintes locales (culturelles, commerciales ou réglementaires).

En adoptant ce modèle, les développeurs peuvent concevoir des formulaires plus cohérents, conviviaux et facilement réutilisables, tout en accélérant leur développement et leur déploiement. Cela se traduit par une amélioration notable de l’expérience utilisateur, une réduction des coûts de maintenance et une meilleure évolutivité. JSONForms s’impose ainsi comme un outil stratégique pour relever les défis de la complexité, de la localisation et de la maintenabilité dans les applications mobiles modernes.

Being an ethical software engineer

par Xavier F. Bouchet

Une prise de conscience récente

Dans le monde du développement logiciel, la question de l’éthique se pose de plus en plus ces dernières années. Les développeurs prennent conscience du sens de leur travail, et remettent parfois en question la finalité des outils qu’ils développent.
C’est ce qu’a voulu aborder dans son talk Xavier F. Bouchet, Staff Engineer à Datadog.

Il est parti de la réponse donnée à cette question dans un questionnaire Stackoverflow en 2018 : 58.5% des développeurs refuseraient d’écrire du code qu’ils jugent contraire à l’éthique.

Cette réflexion est d’autant plus importante car le numérique est totalement ancré dans nos vies, donc les développeurs ont “le pouvoir” de contribuer à des choses qui touchent un nombre conséquent d’utilisateurs, notamment via les smartphones que quasiment tout le monde possède.

Entre zone grise et responsabilité

Xavier aborde ensuite quelques notions importantes à son talk. Il explique que le développement logiciel se situe parfois dans une zone extralégale (en dehors de la légalité), une sorte de zone grise où les frontières ne sont pas toujours clairement définies. Face à cela, deux approches philosophiques majeures émergent : le conséquentialisme, qui évalue une action par ses conséquences et va permettre de définir si elle est morale ou immorale, et la déontologie, qui soutient que certains actes sont intrinsèquement bons ou mauvais.

Il explique ensuite que le cerveau a des biais cognitifs, il doit parfois réfléchir vite et avec trop d’informations. Il peut alors prendre des décisions qui ne sont parfois pas les bonnes. Il prend comme exemple le scandale des moteurs Volkswagen en 2015 (NDLR : étant un grand fan du Youtubeur Sylvain Levy, je vous laisse une vidéo dans laquelle il explique très bien ce scandale : https://www.youtube.com/watch?v=Q9EgFbHbj-k&ab_channel=SylvainLyve).Un autre exemple de biais cognitif concerne les représentations stéréotypées générées par les IA, avec notamment les secrétaires qui sont majoritairement de sexe féminin (car basé sur des préjugés)

.

Adopter une démarche éthique vis-à-vis du produit

Le principal conseil donné par Xavier pour être éthique vis-à-vis du produit est de se mettre à la place de l’utilisateur afin de comprendre son besoin et comment il va utiliser la fonctionnalité développée. Il suggère de se poser différentes questions : est-ce que la fonctionnalité a du sens ? Est-ce qu’elle résout un problème ? Est-ce qu’elle est accessible ? Est-ce qu’elle est utilisable de façon fluide et intuitive ? Est-ce que cela va améliorer son bien-être ou sa vie quotidienne ?
L’idée est de pouvoir prendre du recul sur ce qu’on nous demande de faire, et surtout de se poser la question de savoir si on devrait le faire, au lieu de se focaliser sur la question de si on peut le faire. Tout cela pour dire que savoir dire “non” à une fonctionnalité est une compétence cruciale.
Pour illustrer tout ça, il utilise une citation du film Jurassic Park :

Enfin, être éthique vis-à-vis du code

Xavier avance dans son talk en listant une série de questions à se poser pour adopter une démarche éthique vis-à-vis du code. Le code peut-il être utilisé de façon malveillante et comment ? Doit-on corriger tous les bugs ? Sinon, lesquels en premier ? Quelle stack technique ? Quelle CI ?
L’idée est de prendre possession de son code, et de chercher à l’améliorer, pour toujours le laisser dans un meilleur état que celui dans lequel il a été trouvé.

Xavier termine son talk par une ouverture et des questions émergentes vis-à-vis de l’IA : menace-t-elle la créativité humaine ? Qui détient les droits sur les créations générées par ces outils ?  Dans ce contexte, il est plus important que jamais de placer l'humain au début et à la fin de toute démarche de conception.

Conclusion

Bien évidemment, toute cette réflexion sur l’éthique ne peut pas être systématiquement faite dans le cadre d’un projet, car il peut y avoir de réelles contraintes empêchant toute marge de manœuvre.
Mais l’idée de ce talk est d’apporter une certaine prise de recul sur notre rôle en tant que développeur logiciel, afin de se sentir plus aligné entre notre métier et nos valeurs.