Le local d'abord, le cloud en secours : une configuration hybride pragmatique
Nous ne cachons pas notre position : le local d'abord, toujours. Mais être honnête au sujet de l'IA locale, c'est admettre qu'il existe des moments où un modèle 7B sur votre portable ne peut pas traiter une tâche qu'un modèle cloud de 400B abat sans effort. L'erreur est d'en conclure qu'il faut vivre dans le cloud. Non. Il faut faire du local le choix par défaut et traiter le cloud comme un recours qu'on active délibérément — pas une habitude dans laquelle on glisse.
C'est la configuration hybride que nous recommandons réellement : le local pour tout, le cloud pour la rare exception.
Le mauvais hybride
La plupart des conseils « hybrides » en ligne signifient en réalité le cloud d'abord, le local pour s'amuser. Chaque requête part chez un fournisseur, et le modèle local est une curiosité qu'on lance le week-end. Ce n'est pas de l'hybride — c'est du cloud avec des étapes en plus. Vos données partent quand même, la facture grimpe quand même, votre flux de travail casse quand même dès que la connexion tombe.
Un hybride souverain inverse le défaut. Le local fait le travail. Le cloud est la sortie de secours.
Quand le local doit rester local
Gardez-le sur votre machine — sans exception — dès que l'une de ces conditions est vraie :
- La donnée est sensible. Fichiers clients, dossiers médicaux, code propriétaire, tout ce qui est sous NDA ou RGPD. Si ça ne doit pas sortir des murs, ça ne doit pas sortir de la machine. C'est tout l'intérêt du RAG respectueux de la vie privée.
- La tâche est routinière. Résumer, rédiger, reformater, l'aide au code du quotidien — un modèle local bien choisi fait cela toute la journée, gratuitement. Payer un fournisseur cloud au token pour un travail que votre portable fait très bien n'est que du gaspillage, comme le montrent les chiffres de notre comparaison des coûts.
- Vous en avez besoin hors ligne ou fiable. Dans un avion, sur un mauvais wifi, ou pendant une panne d'un fournisseur, le modèle local fonctionne, tout simplement.
Pour la grande majorité de ce que les gens font réellement avec un LLM, l'histoire s'arrête là. Pas besoin de cloud.
Quand un recours au cloud se défend
Il existe une bande étroite de tâches où un modèle cloud de pointe gagne vraiment sa place :
- Un problème de raisonnement ponctuel bien au-delà de la taille de votre modèle local — une question d'architecture ardue, une preuve difficile, un plan de refactorisation à grande échelle.
- Un travail sur des données publiques, non sensibles où le surcroît de capacité en vaut la peine et où la confidentialité n'est pas en jeu.
- Une capacité que votre matériel ne peut tout simplement pas héberger encore — une fenêtre de contexte géante, une modalité spécialisée.
Le mot-clé est recours. Vous escaladez vers le cloud consciemment, pour une tâche précise, après avoir décidé que la donnée peut être envoyée sans risque — pas parce que c'était le chemin de moindre résistance.
Ne laissez jamais un recours devenir automatique pour des données sensibles. Un script « si le local peine, réessaie sur le cloud » enverra joyeusement vos fichiers confidentiels à un tiers dès que votre modèle local hésite. La décision d'escalade doit être la vôtre, prise tâche par tâche — jamais un choix par défaut silencieux.
Une règle de décision simple
Avant toute requête, posez-vous deux questions, dans l'ordre :
- La donnée est-elle sensible ? Si oui → local, point final. Aucun recours, jamais.
- Mon modèle local peut-il le faire assez bien ? Si oui → local. Ce n'est que si la réponse est non, et que la question 1 était aussi non, que le cloud devient une option.
C'est tout. Deux questions vous gardent souverain par défaut et pragmatique en bordure. Le cloud cesse d'être l'endroit où vit votre IA et devient un outil que vous empruntez à l'occasion — en connaissance de cause.