Sharebox a démarré d'une frustration simple : Plex et Jellyfin sont des usines à gaz quand tu veux juste envoyer un lien de film à quelqu'un. Le projet a pris forme en quelques jours de travail dense, avec une IA comme pair permanent. Ni vibe coding, ni délégation aveugle — quelque chose entre les deux, et assez différent des deux.
Ce que j'ai appris sur ce mode de travail ne ressemble pas à ce qu'on lit habituellement. Ni l'enthousiasme naïf ("l'IA code à ta place"), ni le scepticisme de posture ("ça ne vaut rien"). C'est plus subtil, et surtout très visible dans l'historique git.
Un projet, pas un prompt
Le choix de la stack a été délibéré et contre-courant : PHP 8.1 pur, SQLite en WAL mode, zéro dépendance externe. Pas de framework, pas de composer au démarrage. L'IA a poussé vers Laravel plusieurs fois. J'ai dit non.
C'est là que commence le peer programming réel. L'IA optimise pour ce qu'elle a vu le plus souvent dans ses données d'entraînement : des projets Laravel, des ORMs, des couches d'abstraction. Elle a raison dans 80% des cas. Pour un self-hosted file sharing où la contrainte principale est "aucun prérequis système sauf PHP et SQLite", elle a tort.
Le résultat : une base SQLite créée automatiquement au premier lancement, un fichier de configuration auto-généré depuis les variables d'environnement, Docker-ready sans que ça soit la seule option de déploiement. L'IA a contribué à l'implémentation de ces choix une fois qu'ils étaient posés — mais les choix, c'est moi qui les ai posés.
Le peer programming IA ne fonctionne que si tu sais où tu vas. L'IA est un excellent exécutant et un bon contradicteur. Elle n'est pas un architecte.
Ce que ça change concrètement
Prenons trois exemples de problèmes réels où le pair avec l'IA a réellement accéléré les choses.
Les trois modes de streaming
Sharebox streame des vidéos. Le problème : un fichier H.264/AAC dans un container MKV ne peut pas être streamé directement dans un navigateur. Un fichier H.265 ne peut pas être lu sur iOS. Un fichier avec des sous-titres image (PGS) ne peut pas être affiché nativement.
La solution : trois modes. Native pour ce qui passe sans rien faire (MP4/H.264, zéro CPU). Remux pour changer le container sans re-encoder (MKV → MP4, CPU minimal). Transcode pour tout le reste (ffmpeg, CPU élevé).
L'IA a produit le code de détection de codec via ffprobe rapidement. Ce qui aurait pris une journée de lecture de documentation s'est fait en deux heures. La logique de décision entre les trois modes — c'est moi qui l'ai écrite, après avoir challengé chaque proposition de l'IA qui mélangeait les cas.
Le file-lock pour les workers FPM
PHP-FPM crée des workers en parallèle. Quand un navigateur ouvre deux onglets ou qu'un player iOS fait des requêtes de range en parallèle, plusieurs workers peuvent démarrer simultanément le même processus ffmpeg. Le résultat : un CPU à 800%, des fichiers de sortie corrompus.
J'ai décrit le problème. L'IA a proposé un mutex Redis. J'ai dit non — Redis est une dépendance, on reste sans dépendance. Elle a proposé un lock fichier. On a implémenté ça ensemble : un fichier .lock par segment, flock() avec LOCK_EX | LOCK_NB, timeout si le lock ne s'acquiert pas en 30 secondes.
Le pair a fonctionné ici parce que le problème de concurrence est exactement le type de chose où l'IA excelle — c'est un pattern connu, documenté, avec des solutions éprouvées. Mon rôle était de contraindre la solution aux règles du projet.
Le cache de sous-titres
Extraire des sous-titres d'un MKV avec ffmpeg prend 15 à 20 secondes pour un fichier de 2h. Inacceptable au moment du play. La solution : extraction en background au premier accès, cache sur disque ensuite.
L'IA a écrit le mécanisme de cache. Puis on a découvert un bug : le navigateur mettait en cache la réponse HTTP vide (pendant l'extraction), et les requêtes suivantes retournaient du vide même une fois l'extraction terminée. L'IA a proposé des headers Cache-Control: no-cache. Correct. Le gain final : 20 secondes de latence éliminées sur les lectures suivantes.
Les limites que personne ne dit
Le peer programming avec l'IA a des angles morts. Pas les bugs évidents — ceux-là, l'IA les corrige souvent mieux et plus vite que moi. Les angles morts structurels.
Le contexte projet ne persiste pas. À chaque session, l'IA repart de zéro. Elle ne sait pas que tu as décidé de ne pas ajouter de système d'authentification. Elle ne sait pas que le déploiement doit tenir sur un VPS à 3€. Elle va te proposer des JWT, des refresh tokens, un Redis pour les sessions. Tu dois réexpliquer les contraintes à chaque fois — ou utiliser un CLAUDE.md bien tenu.
Elle ne maintient pas la discipline de scope. C'est le problème le plus insidieux. "On pourrait aussi ajouter..." est une phrase que l'IA dit souvent. Un système de notifications. Une API REST complète. Un système de playlists. Chaque suggestion est raisonnable prise isolément. Ensemble, elles transforment un outil simple en monstre de complexité. Dire non régulièrement est une compétence à part entière dans ce mode de travail.
Elle accepte trop facilement. Si tu proposes une approche bancale, elle va l'implémenter proprement. Le pair humain aurait dit "attends, t'es sûr ?" L'IA par défaut dit "voici l'implémentation". Il faut apprendre à lui demander explicitement de challenger tes choix.
Le pattern qui fonctionne
Après plusieurs sessions sur sharebox, le pattern qui produit les meilleurs résultats est le suivant :
Pair review, pas délégation. "Écris-moi la fonction de streaming" donne quelque chose qui marche mais qui ne respecte pas les contraintes du projet. "Voici mon implémentation, qu'est-ce qui pose problème ?" donne quelque chose d'utile.
Décrire le problème, pas la solution. "J'ai un problème de concurrence sur les workers FPM quand plusieurs requêtes arrivent en même temps" est bien meilleur que "implémente un mutex". La deuxième formulation te donne une réponse générique. La première déclenche une vraie réflexion sur le contexte.
Ne jamais accepter la première solution. Pas parce qu'elle est mauvaise — elle est souvent correcte. Mais parce qu'il y a presque toujours une contrainte que l'IA n'a pas prise en compte. Demander "quelles sont les alternatives ?" et "quelles sont les limites de cette approche ?" révèle systématiquement quelque chose d'utile.
Garder la main sur le git. Chaque commit est une décision. L'IA ne commite pas — toi oui. Cette friction minime est saine : elle force à lire ce qui va dans le dépôt plutôt que de merge en aveugle.
Ce que le git log révèle
L'historique de sharebox sur les derniers jours montre quelque chose d'intéressant : les commits récents sont presque tous des corrections et des durciessements, pas des features.
Sanitisation des noms de fichiers dans Content-Disposition pour prévenir l'injection. Correction d'un bug de hoisting iOS où la détection du navigateur était appelée avant l'initialisation. Fix d'un cache poisoning sur les sous-titres causé par le cache du navigateur. Correction d'une duplication de processus ffmpeg depuis des requêtes en double.
C'est ça la réalité du peer programming IA sur un projet de quelques jours : la vitesse d'itération est réelle. Tu arrives vite à un premier état fonctionnel. Ensuite commence le travail de consolidation — et là, l'IA est moins utile que pour la phase de construction. Les bugs de timing, les race conditions, les edge cases de comportement navigateur : l'IA propose des solutions, mais diagnostiquer le problème réel demande souvent une lecture attentive des logs que l'IA ne peut pas faire à ta place.
Le refactoring aussi est visible : plus de 1000 lignes de JS/CSS extraites en fichiers séparés. Ce nettoyage, c'est moi qui l'ai voulu. L'IA l'a bien exécuté, mais elle n'en avait pas besoin — elle aurait continué à rajouter du code dans le même fichier sans se plaindre.
Conclusion
Sharebox fonctionne. Il tourne sur un NAS, sert des films, gère les sous-titres, survit aux requêtes parallèles. Il a pris une fraction du temps qu'il m'aurait fallu seul.
Ce que le peer programming IA a changé, c'est la vitesse d'itération sur les problèmes connus. Streaming vidéo, gestion de concurrence, détection de codec : des domaines documentés où l'IA est opérationnelle rapidement. Ce qu'il n'a pas changé : les décisions de scope, l'architecture, la discipline à ne pas sur-ingénierer. Ces décisions restent humaines, et elles ont un impact direct sur la qualité du résultat.
Le vrai gain n'est pas "l'IA code à ma place". C'est "j'ai un pair disponible 24h/24 qui connaît la plupart des patterns, ne se fatigue pas, et peut implémenter ce que je valide". C'est différent. Et c'est déjà beaucoup.