Construire des outils d'IA entre deux trajets Uber : comment j'ai transformé le temps mort en or de développement
Bonjour, je m'appelle Chris. Je suis un ancien artisan devenu conducteur VTC ici à Vancouver, et j'ai découvert quelque chose d'assez incroyable. Dans l'heure et demie que j'ai en moyenne entre les courses chaque jour, j'ai appris à construire des applications alimentées par l'IA sur mon téléphone. Ce que j'ai accompli dans ces moments de temps mort dispersés est, franchement, surprenant — même pour moi.
Je n'ai pas quitté les métiers de l'artisanat par choix. Une scie Skil a emporté la majeure partie de mon pouce, et voilà. Plus de vingt ans comme peintre, plombier et charpentier, et un mauvais moment a tout arrêté. Je ne vais pas prétendre que je n'en ai pas été amer pendant un moment. Mais voici le truc avec le fait d'être artisan : même quand les outils changent, l'état d'esprit de résolution de problèmes ne change pas. Quand vous rencontrez un obstacle, vous n'attendez pas que quelqu'un d'autre le répare. Vous construisez une solution.
Cet état d'esprit s'est parfaitement transposé dans le développement logiciel, même si j'admets que cela a des inconvénients. Chaque fois que je rencontre un obstacle dans mon parcours de codage — et croyez-moi, je les rencontre régulièrement — je construis un outil autour du problème. C'est comme quand je tombe sur une rivière que je ne peux pas traverser, je construis simplement un pont. Et cette approche a été absolument libératrice, même si parfois un abonnement mensuel aurait pu résoudre le même problème plus efficacement.
L'état d'esprit de l'artisan : résoudre des problèmes en code
Les parallèles entre le travail artisanal et le développement logiciel sont plus profonds qu'on ne le pense. En menuiserie, quand il vous manque un gabarit spécifique, vous en construisez un à partir de chutes de bois. En plomberie, quand vous ne trouvez pas le bon adaptateur, vous fabriquez un raccord temporaire. Ce genre de bricolage — utiliser les matériaux disponibles pour créer des solutions de contournement — devient une seconde nature.
Mais le développement logiciel ajoute des couches de complexité que les métiers physiques n'ont pas. Quand un menuisier construit un gabarit, ça marche ou ça ne marche pas. Si ça casse, c'est évident. Quand je construis une application personnalisée, les modes de défaillance sont plus insidieux. Un cas limite non géré peut silencieusement interrompre une connexion, une dépendance peut avoir une vulnérabilité qui passe inaperçue pendant des mois, et le code lui-même devient un passif qui exige une attention continue.
Le romantisme de construire ses propres outils est réel, cependant. Il y a quelque chose de profondément satisfaisant à élaborer une solution qui correspond exactement à votre flux de travail, optimisée pour vos besoins spécifiques plutôt que pour les hypothèses d'un chef de produit sur ce que veulent les utilisateurs. La question avec laquelle je lutte constamment est : quand cette approche sert-elle la productivité, et quand devient-elle du sur-ingénierie déguisé en résolution de problèmes ?
Le premier pont : mon client SSH personnalisé
Ma création phare est une application iOS que j'appelle Terms — actuellement dans sa quatrième itération. Ce client SSH a évolué au fil d'années d'utilisation réelle pendant ces moments dispersés entre les courses, et il est devenu parfaitement adapté à mon flux de travail unique de copier-coller, discours-texte et codage piloté par l'IA.
L'application utilise l'authentification biométrique — Face ID spécifiquement. Quand je l'ouvre, le système authentifie mon visage et me dépose directement dans mon environnement d'hébergement VPS, juste à la ligne de commande. La technologie derrière Face ID est fascinante : le système TrueDepth d'Apple projette plus de 30 000 points invisibles pour créer une carte de profondeur précise de votre visage, en utilisant l'imagerie infrarouge pour fonctionner même dans l'obscurité.
La capacité à rester confortablement sur mon téléphone, à construire des outils qui ont un réel potentiel tout en corrigeant constamment des bugs et en optimisant — c'est une vraie joie. Je le recommande vivement. Et oui, il y a quelque chose de discrètement satisfaisant dans le fait que les mêmes mains qui encadraient des murs et soudaient des tuyaux en cuivre déploient maintenant du Python sur un serveur Linux depuis un parking à Vancouver.
Une de mes fonctionnalités préférées répond à une frustration courante dans les environnements de développement mobiles. Quand je rencontre un bug ou une trace d'appel qui bloque le terminal, je balaye simplement vers le haut pour fermer l'application, je la rouvre, je laisse Face ID m'authentifier à nouveau, et je suis immédiatement de retour à la ligne de commande, prêt à continuer. Ce processus de récupération transparent m'a sauvé d'innombrables heures de frustration et maintient mon élan pendant ces précieuses sessions de codage entre les courses.
L'implémentation technique repose sur le stockage de clés SSH chiffrées dans le trousseau iOS, qui offre une sécurité basée sur le matériel sur les appareils dotés d'une enclave sécurisée. La gestion de l'état de connexion a été l'une des parties les plus délicates à maîtriser — gérer les transitions réseau lorsque je me déplace entre différentes antennes cellulaires et points d'accès WiFi à travers la ville. J'ai implémenté une couche de persistance de connexion qui peut détecter les changements réseau et se reconnecter automatiquement à la session distante, souvent si parfaitement que je ne remarque même pas que la transition a eu lieu.
Aurais-je pu obtenir des fonctionnalités similaires avec des clients SSH existants ? Absolument. Mais ces applications optimisent pour des cas d'usage généraux, tandis que la mienne est concentrée sur mon flux de travail spécifique. Les raccourcis clavier personnalisés, l'intégration avec le discours-texte d'iOS pour coder par la voix, et la gestion spécialisée du presse-papiers pour échanger des extraits de code entre mon téléphone et le serveur — ces fonctionnalités existent parce que je les ai construites pour mes besoins exacts.
Le pont vidéo-vers-audio : résoudre les frictions du flux de travail de contenu
Le deuxième outil majeur que j'ai développé est né d'un point de friction spécifique dans mon flux de travail de création de contenu. J'avais besoin d'un moyen fiable de transcrire des vidéos, et bien qu'il existe des services web pour cela, je voulais quelque chose de plus flexible pour ma bibliothèque de contenu personnelle.
Mon approche a été de d'abord convertir les vidéos en audio — un processus beaucoup plus léger que le téléchargement de gros fichiers vidéo. Pendant des années, je me suis appuyé sur une application tierce pour cela, mais quand les mises à jour iOS la cassaient ou que j'avais besoin de formats audio spécifiques, je me retrouvais bloqué. Alors j'ai construit mon propre convertisseur.
La technologie sous-jacente repose sur FFmpeg, un puissant outil open-source mu...
Get new posts
Subscribe in your language
New posts delivered to your inbox. Unsubscribe anytime.
Receive in: