N'attendez pas la fonctionnalité — modifiez vous-même l'application

Je voulais ouvrir Telegram et voir un flux unique regroupant les publications non lues des seuls canaux que j’avais choisis. Ce bouton n’existait pas. Je n’ai pas envoyé de demande pour attendre ensuite de voir si elle finirait dans la feuille de route de quelqu’un d’autre. J’ai ouvert le code source du client Android officiel, décrit le comportement à Claude, branché mon téléphone et, le soir même, utilisé ma propre version de l’application.

Le matin même, cette fonctionnalité n’existait pas

Les abonnements à des canaux finissent généralement dans l’une de ces deux situations, aussi mauvaises l’une que l’autre : des centaines de compteurs rouges, ou tout marqué comme lu tandis que les publications utiles disparaissent. Je voulais un troisième modèle : choisir moi-même quelques canaux, puis lire toutes leurs publications non lues dans une seule chronologie ordinaire.

L’onglet Digest obtenu fait exactement cela :

• il permet de rechercher des canaux et rassemble leurs publications par ordre chronologique ;
• il conserve, pour chaque compte, un repère de dernière lecture distinct ;
• il s’ouvre sur le premier élément non lu et permet de remonter indéfiniment dans le passé ;
• il affiche les noms des canaux, albums multimédias, dates et réactions avec l’interface de Telegram ;
• il marque les messages visibles comme lus par le même mécanisme qu’un canal normal.

Ce n’est ni une minuscule démonstration ni un nouveau client redessiné de zéro. L’agent a dû mettre la base à niveau vers la dernière source publiée de Telegram, comprendre sa base de données locale, la pagination, le regroupement des médias et la navigation. Mais je n’ai pas eu à lui dicter des noms de classes. J’ai décrit ce que la personne qui l’utilise devait voir et ressentir.

Le prompt décrivait le comportement, pas le code

La demande centrale ressemblait à peu près à ceci. La dernière phrase était importante : elle a empêché l’agent de construire, à côté de l’interface existante de Telegram, une seconde interface manifestement étrangère à l’application.

Ajoute une page distincte contenant tous les messages non lus des canaux Telegram que je sélectionne.

J’ai besoin d’un sélecteur de canaux. Conserve un repère Digest distinct pour le dernier élément que j’ai réellement lu. À l’ouverture de la page, place-la sur le premier message non lu. Ajoute un défilement infini vers le passé et un bouton en bas qui ramène au premier élément non lu. Marque les publications visibles comme lues au moyen de l’état de lecture standard de Telegram.

Affiche les albums, le nom du canal et son avatar exactement comme Telegram le fait normalement. Réutilise autant que possible l’interface existante ; n’écris une interface personnalisée que là où c’est inévitable.

Compile l’application, installe-la sur le téléphone connecté et vérifie le résultat sur l’appareil.

Quelques heures plus tard, l’application fonctionnait sur un Redmi Note 8 Pro. J’ai alors donné deux brèves instructions supplémentaires : supprimer les à-coups du défilement, puis déplacer le bouton rond au-dessus de la navigation inférieure tout en retirant un avatar parasite entre les messages. Claude a examiné le résultat sur le téléphone, trouvé les causes, recompilé l’APK et vérifié à nouveau. Cela ressemblait davantage à un travail avec une équipe produit qu’à de la « génération de code ».

Le code devient moins cher ; une intention précise gagne en valeur

Il existait autrefois une chaîne coûteuse entre « j’ai besoin de ceci » et « je l’utilise » : trouver un développeur Android, expliquer l’architecture, assembler l’environnement, attendre les compilations et apprendre ADB. Cela nous a habitués à considérer l’interface d’une application comme définitive. Nous acceptons ce que l’éditeur livre et attendons la version suivante.

Un agent de codage change l’économie de cette chaîne. Il peut lire un vaste dépôt inconnu, faire correspondre les versions du JDK, du SDK et du NDK, trouver le bon point d’intégration, compiler un APK, examiner un échec d’installation, lire logcat et recommencer. Tous les résultats ne sont pas bons, mais le coût d’une première version fonctionnelle s’est effondré.

Cela ne s’applique pas à tout. Une application fermée sans code source, une fonctionnalité côté serveur, une infrastructure de paiement ou une modification de protocole cryptographique n’apparaîtront pas grâce à un seul prompt. Mais lorsque le comportement souhaité se trouve dans un client Android ouvert et peut être vérifié à l’écran, attendre le bouton officiel n’est plus toujours rationnel.

Comment faire de même : ne laisser à l’humain que les actions indispensables

Le processus ci-dessous concerne ce fork. Il vous faut un ordinateur, un agent de codage capable d’utiliser le terminal, comme Claude Code ou Codex, un téléphone Android, un câble USB de données et plusieurs gigaoctets d’espace libre. Le dépôt est volumineux et la première compilation Android prend du temps. Laissez l’agent préparer l’environnement technique ; vous ajouterez les identifiants privés, modifierez les réglages du téléphone et vous connecterez à Telegram.

1 Laisser l’agent préparer le projet

Ouvrez l’agent dans un dossier vide et collez le prompt ci-dessous. Il s’arrête volontairement avant les secrets et refuse de supprimer une application installée si Android signale un conflit de signature.

Prépare https://github.com/howaihelps/tg-digest-android pour une compilation locale.

Travaille de façon autonome : clone le projet, lis son README et inspecte l’historique Git ainsi que l’arbre de travail. Détecte mon système d’exploitation et vérifie Git, JDK 17, Android SDK / Build Tools 35, NDK 27.2.12479018, CMake et platform-tools. Prépare ce qui manque ; si un téléchargement ou une installation nécessite mon autorisation, demande-la une seule fois et explique précisément pourquoi.

N’affiche, ne transmets et ne committe jamais TELEGRAM_API_ID ni TELEGRAM_API_HASH. Vérifie que le fichier local.properties à la racine est ignoré par Git. S’il n’existe pas, crée un modèle sûr contenant uniquement le bon sdk.dir et des valeurs temporaires pour les deux champs, puis arrête-toi et demande-moi de les remplir manuellement.

Ne compile et ne pousse encore rien. Termine en indiquant uniquement le chemin du dépôt, l’état de préparation de la chaîne d’outils, le chemin de local.properties et ma prochaine action.

2 Obtenir son propre ID API et hash Telegram

Il ne s’agit pas d’un token de bot. Telegram délivre une paire par numéro de téléphone et exige un ID personnel pour un client tiers. Consultez les instructions officielles de Telegram.

À la racine du dépôt cloné, à côté de settings.gradle, ouvrez local.properties et remplacez manuellement les valeurs temporaires. N’ajoutez pas de guillemets :

sdk.dir=/Users/[VOTRE_NOM]/Library/Android/sdk
TELEGRAM_API_ID=[VOTRE_API_ID_NUMERIQUE]
TELEGRAM_API_HASH=[VOTRE_API_HASH_DE_32_CARACTERES]

Le chemin sdk.dir est différent sous Windows et Linux ; l’agent devrait déjà l’avoir renseigné. Dans ce fork, TMessagesProj/build.gradle injecte les deux valeurs dans BuildConfig, puis BuildVars.java les lit à l’exécution. local.properties figure dans .gitignore.

Au moment de la publication, j’ai également comparé mes vraies valeurs à chaque fichier des deux commits publics : mes api_id et api_hash personnels ne figuraient ni dans l’arbre alors publié ni dans l’historique Git. La source amont importée contient bien la paire d’exemple standard et restreinte de Telegram. Ce ne sont pas mes identifiants, et vous ne devez pas vous en servir pour votre compilation.

3 Préparer le téléphone

Le nom des menus varie selon les fabricants. La séquence de base est décrite dans le guide officiel Android sur les options pour les développeurs. Gardez l’écran déverrouillé pendant la première installation : un agent ne peut pas accepter une boîte de dialogue système à votre place.

4 Demander à l’agent de compiler et de lancer

Une fois local.properties complété et le téléphone branché, envoyez le prompt suivant. C’est l’instruction de lancement. Les commandes attendues du README y figurent, mais vous n’avez pas besoin de les comprendre ni de les exécuter vous-même.

Les identifiants dans local.properties sont renseignés et le téléphone Android déverrouillé est connecté en USB. Compile et exécute l’application dessus.

Travaille jusqu’à obtenir un résultat vérifiable. N’affiche pas TELEGRAM_API_ID ni TELEGRAM_API_HASH et, avant toute action Git, vérifie que local.properties n’est pas suivi.

1. Exécute adb devices -l. Si l’état est unauthorized, demande-moi d’accepter la boîte de dialogue RSA, puis continue.
2. Vérifie l’ABI avec adb shell getprop ro.product.cpu.abilist. Ce fork ne compile actuellement que pour arm64-v8a. Si le téléphone ne prend pas en charge arm64-v8a, adapte la configuration ABI avec le changement le plus limité et explique-le.
3. Prépare PATH, JAVA_HOME, ANDROID_HOME et ANDROID_SDK_ROOT ; rends la version de CMake installée compatible avec Gradle.
4. Exécute ./gradlew :TMessagesProj_App:assembleAfatDebug. Corrige les erreurs d’environnement ou de compilation au lieu de t’arrêter à la première.
5. APK attendu : TMessagesProj_App/build/outputs/apk/afat/debug/app.apk. Installe-le avec adb install -r.
6. Si l’installation est bloquée, demande-moi d’activer Installer via USB. Si Android signale un conflit de signature, NE désinstalle PAS l’ancienne application sans mon autorisation explicite : la désinstallation efface ses données locales.
7. Lance le package org.telegram.messenger.beta et vérifie que le premier écran s’ouvre et que l’onglet Digest est présent. Utilise adb, logcat et des captures d’écran pour le diagnostic.

Termine en indiquant le chemin et la taille de l’APK, l’ABI de l’appareil, le résultat de l’installation, le package/l’activité lancés et ce que je dois vérifier visuellement. Ne pousse rien.

La configuration actuelle a été vérifiée sur arm64-v8a : un APK de débogage d’environ 75 Mo a été compilé, installé et lancé sous le nom org.telegram.messenger.beta. Au premier lancement, vous devez encore vous connecter vous-même à Telegram et saisir le code de connexion, ainsi que le mot de passe à deux facteurs si vous l’avez activé. Ne les communiquez pas à l’agent.

5 Formuler sa fonctionnalité en termes de résultats

Après le lancement de l’application, vous pouvez modifier ce fork ou répéter le processus avec une autre application open source. Ne commencez pas par « crée une classe » ou « corrige le RecyclerView ». Décrivez la situation, le comportement observable et les critères d’acceptation.

Modifie l’application qui fonctionne sur mon téléphone pour ce besoin personnel.

Problème : [ce que je fais actuellement à la main ou ce qui manque].
Comportement souhaité : [ce que je dois voir et ce qui doit se produire après chaque action].
Données et état : [ce qu’il faut stocker, quand le mettre à jour, ce qui doit survivre à un redémarrage].
Limites : [ce qui ne doit pas changer ; les écrans et comportements natifs à conserver].
Terminé lorsque :
- [critère vérifiable 1] ;
- [critère vérifiable 2] ;
- [critère vérifiable 3].

Commence par trouver les composants et les flux de données existants dans le code source. Réutilise autant que possible l’interface et l’architecture propres à l’application. Implémente ensuite la plus petite version complète, compile-la, installe-la sur le téléphone connecté et vérifie toi-même chaque critère. Montre le résultat dans une capture d’écran et dresse la liste des compromis. Ne pousse rien sans instruction distincte.

6 Corriger les sensations, pas seulement la compilation

La première version de Digest fonctionnait, mais le flux tressautait légèrement au chargement d’éléments supplémentaires. Le prompt suivant ne contenait aucun diagnostic, seulement une observation et l’exigence d’un résultat mesuré :

Sur le téléphone physique, le flux tressaute lorsque la pagination se déclenche pendant le défilement. Reproduis toi-même le problème, mesure les images saccadées / le temps par image, trouve la cause, corrige-la sans modifier le comportement du flux, réinstalle l’APK et répète exactement la même mesure. Ne considère pas la tâche comme terminée au seul motif que le code compile.

L’agent a découvert qu’une actualisation complète de la liste se produisait pendant la pagination et l’a remplacée par une mise à jour incrémentale. Lors de la nouvelle mesure, la proportion d’images saccadées est passée de 11,9 % à 2,1 %, tandis que le temps d’image au 99e percentile est passé de 40 à 22 ms. J’ai décrit un autre défaut visuel encore plus simplement : « déplace le bouton au-dessus de la navigation inférieure et supprime l’artefact au centre, tout en conservant le nom du canal ». Le compromis final est un en-tête avec le nom seul : l’avatar d’auteur qui provoquait l’artefact n’est pas affiché. Cette boucle — regarder, nommer le défaut, laisser l’agent le reproduire, puis vérifier — compte davantage qu’un premier prompt parfait.

Avant de publier, utiliser un prompt de sécurité distinct

Un APK fonctionnel ne garantit pas la sûreté d’un dépôt. Avant de pousser, demandez à l’agent d’analyser les fichiers suivis et tout l’historique qui sera publié à la recherche de secrets, d’afficher le diff avec l’amont, de préserver la licence et de ne pas présenter un APK de débogage comme un client officiel.

Prépare les modifications pour publication, mais effectue d’abord un audit de sécurité et de licence.

Inspecte git status, git diff, chaque fichier suivi et l’intégralité de l’historique qui sera publié à la recherche de mes vrais TELEGRAM_API_ID et TELEGRAM_API_HASH, de tokens, mots de passe, clés de signature et chemins absolus privés. N’affiche aucune valeur secrète trouvée ; indique seulement son type, le fichier concerné et une correction sûre. Vérifie que local.properties est ignoré et n’a jamais été suivi.

Compare les modifications avec l’amont, conserve les mentions de copyright et respecte les obligations de licence. Indique dans le README qu’il s’agit d’une version personnelle non officielle, précise les versions et ABI testées, l’endroit où saisir localement les identifiants et la procédure de compilation de l’APK.

Montre-moi la liste finale des fichiers et le résultat de l’audit. Ne committe et ne pousse qu’après mon autorisation explicite.

Telegram pour Android est distribué sous GNU GPL v2 ou version ultérieure ; le fork conserve donc la licence et met le code source à disposition. Il existe aussi une obligation pratique : maintenir son fork, examiner son diff et ne pas considérer du code généré comme automatiquement digne de confiance. Un agent réduit radicalement le coût de l’implémentation ; il ne supprime pas la responsabilité du propriétaire.

Pas une application pour tout le monde — une application exactement pour vous

Un produit grand public doit choisir des fonctionnalités qui ont du sens pour des millions de personnes. Une version personnelle peut être étrange, étroite et parfaite pour une seule personne. C’est là que les agents changent le plus le logiciel : nul besoin de fonder une start-up ni d’attendre des années qu’une demande de fonctionnalité recueille assez de votes. Parfois, un dépôt ouvert, une description précise, un câble USB et la volonté d’examiner le résultat suffisent.

Le code n’est pas devenu inutile. Il est devenu beaucoup moins rare. Le droit de le prendre, de le modifier et de l’exécuter sur son propre appareil a gagné d’autant plus de valeur.

Partager sur Telegram