Aider.

Des modifications suivies dans Git

Lorsqu'une modification concerne plusieurs fichiers liés, les transférer un par un dans un chat web est peu pratique. On lance Aider dans le répertoire du projet et on ajoute les fichiers sources nécessaires à la session. L'assistant reçoit leur contenu, utilise la carte du dépôt comme contexte complémentaire et modifie les fichiers selon la demande. Les changements se suivent dans Git, et les modifications indésirables peuvent être annulées.

La carte du projet aide à trouver des liens, mais ne rend pas le contexte infini. Si vous ajoutez trop de fichiers, les coûts et la probabilité de manquer une exigence importante augmenteront. Il est préférable d'identifier un comportement spécifique, de joindre un exemple reproductible et de ne laisser les documents de référence que là où ils sont vraiment nécessaires.

D'abord la question, puis le changement

Le mode ask permet d'examiner le code existant sans le modifier. Le mode code sert aux modifications, tandis que le mode architect répartit la conception de la solution et son application aux fichiers entre un modèle de planification et un modèle d'édition. Cette distinction est utile : il faut parfois comprendre la cause d'une erreur avant d'autoriser l'outil à modifier l'implémentation.

Par exemple, une fonction d'importation perd les lignes dont un champ facultatif est vide. Demandez d'abord de suivre le parcours d'une de ces lignes et de montrer où elle est écartée. Limitez ensuite la modification au traitement de l'importation, précisez le résultat attendu pour une valeur vide et demandez une vérification. Cette consigne est plus facile à évaluer qu'une demande de « réécrire correctement l'importation ».

Le modèle est sélectionné séparément

Aider se connecte à des fournisseurs cloud et à des modèles locaux, notamment via Ollama. Installer le programme ne donne pas accès gratuitement aux calculs d'un modèle cloud. Dans une configuration locale, le texte est traité par le serveur local choisi ; la qualité des modifications, la vitesse et la longueur de contexte disponible dépendent du modèle et de l'ordinateur.

La possibilité de travailler localement ne s'applique pas automatiquement à chaque exécution. Avec une clé cloud, le contexte concerné est envoyé au fournisseur ; d'autres sources et commandes peuvent aussi accéder au réseau. Avant de travailler sur un projet privé, vérifiez le modèle actif, l'adresse de connexion et les fichiers inclus dans la session. La prise en charge d'API tierces n'implique pas l'existence d'une API cloud distincte propre à Aider.

Comment accepter le résultat

Après la modification, consultez le diff et vérifiez que le cas initial est corrigé, et pas seulement le texte du message d'erreur. Les vérifications lint et les tests automatiques détectent certains problèmes ; leurs commandes et leur environnement doivent être configurés pour votre projet. Vérifiez aussi un fichier ordinaire et une entrée incorrecte pour que la correction ciblée ne perturbe pas un autre parcours.

Un commit Git facilite le retour à l'état précédent, mais ne prouve pas que le code est correct. N'incluez pas de secrets dans le contexte et ne supposez pas que le modèle devinera les conventions d'architecture internes. Préparez plutôt un court fichier de règles accompagné d'exemples réels.

Pour quelles tâches convient-il

• Corriger une erreur reproductible dans plusieurs fichiers
• Discuter du code avant l'édition
• Préparer un Git-diff vérifiable
• Travailler avec votre propre modèle local