Zéro dépendance tierce : quand ça vaut le coup (et quand non)
Retour d'expérience sur le choix zéro dépendance pour Inner Gallery vs l'écosystème riche de Flutter pour Coachy. Les vrais critères de décision.
Zéro dépendance tierce sur Inner Gallery (app de sécurité → surface d'attaque minimale). Des dizaines de packages sur Coachy (app collaborative → vitesse de développement). Le critère : est-ce que la dépendance touche à ce qui te différencie ?
Inner Gallery n'utilise aucune dépendance tierce. Pas de CocoaPods, pas de Swift Package Manager. Uniquement les frameworks Apple natifs — Swift, SwiftUI, CryptoKit, Foundation.
"Pourquoi pas une lib de chiffrement open source ?" Pour une app qui protège les photos les plus privées de ses utilisateurs, je voulais une surface d'attaque minimale.
Le vrai critère : le niveau de confiance requis
La question n'est pas "faut-il éviter les dépendances ?". C'est "quel niveau de confiance ton app exige-t-elle ?".
Pour Inner Gallery, une app qui stocke tes photos les plus privées, chiffrées localement sans jamais quitter ton iPhone, la barre est haute. Très haute. Je ne peux pas me permettre qu'une faille dans une lib tierce compromette le vault photo de mes utilisateurs.
Le niveau de confiance requis détermine ton architecture.
Pour Coachy, mon app de coaching avec IA, j'ai fait le choix inverse. Flutter avec des dizaines de packages : http, riverpod, json_annotation, flutter_secure_storage, etc. Pourquoi cette différence ?
Surface d'attaque vs vélocité
Avec Inner Gallery, chaque ligne de code que je n'écris pas moi-même élargit la surface d'attaque. L'app gère du chiffrement critique, stocke des clés privées, manipule des données ultra-sensibles. L'incident leftpad de 2016 m'a marqué : 11 lignes de JavaScript qui ont cassé la moitié d'Internet.
Plus récemment, le backdoor xz utils de 2024 a montré qu'même les outils les plus basiques peuvent être compromis. Imagine si j'avais utilisé une lib de compression tierce pour Inner Gallery...
Avec Coachy, le contexte change. L'app synchronise avec un serveur, utilise des APIs externes (Gemini), gère des données moins critiques. Ici, la vélocité prime. Flutter sans son écosystème de packages, c'est comme JavaScript sans npm : techniquement possible, humainement masochiste.
Ce que j'ai gagné (et perdu) avec zéro deps
Côté Inner Gallery :
- Auditabilité totale : du code que je maîtrise complètement
- Sécurité garantie : zéro supply chain attack possible, uniquement des frameworks Apple audités
- Performances natives : CryptoKit utilise l'accélération hardware d'Apple Silicon
- Maintenance prévisible : aucune montée de version surprise d'une lib tierce
Mais aussi :
- Moins de confort : pas de helpers tiers pour le boilerplate, tout est écrit maison
- Discipline requise : quand un package résout ton problème en 2 lignes, résister demande de la conviction
Les signaux qui justifient zéro deps
Tu devrais considérer zéro dépendance si :
- Données ultra-critiques : mots de passe, clés privées, photos privées
- Surface d'attaque minimale requise : compliance, audit de sécurité strict
- Contrôle total nécessaire : performances critiques, optimisations spécifiques
- Équipe petite et experte : tu peux maintenir le code custom long terme
Zéro dépendance, c'est un luxe que tu payes en temps de développement. Assure-toi que le ROI security en vaut la peine.
Quand rester dans l'écosystème
Pour la plupart des apps, utilise l'écosystème :
- Apps métier classiques : CRM, e-commerce, réseaux sociaux
- Prototypage rapide : MVP, validation d'idée
- Fonctionnalités commodities : HTTP, parsing JSON, UI components
- Équipes en croissance : onboarding plus simple avec des libs connues
Avec Coachy, je n'aurais jamais fini à temps en réimplémentant Riverpod ou les requêtes HTTP. L'IA de coaching n'exige pas le même niveau de sécurité qu'un vault photo.
Ma règle empirique
Je me pose 3 questions :
- Qu'est-ce qui fuit si une dépendance est compromise ? Photos privées vs données de coaching
- Combien de temps ai-je pour livrer ? 6 mois pour Inner vs 3 mois pour un MVP
- Quelle expertise ai-je sur le domaine ? Crypto = expertise, parsing JSON = commodité
Si les réponses pointent vers "critique/du temps/expertise", alors zéro deps. Sinon, écosystème.
À lire aussi
- Architecture offline-first : mes retours d'expérience
- Apps local-first : pourquoi j'y crois pour certains produits
- Pourquoi j'ai arrêté de faire des sites web
Dire "toujours zéro deps" ou "toujours utiliser l'écosystème" c'est passer à côté du sujet. Ce qui compte, c'est d'adapter ton architecture au niveau de confiance que ton produit exige. Inner Gallery et Coachy ont des besoins différents, ils méritent des approches différentes.
Ta prochaine app stocke des mots de passe ou des likes Instagram ? La réponse détermine ton architecture.