Résolution de conflits par IA sur les pull requests Salesforce

En bref : un conflit de fusion, ce sont deux modifications concurrentes de la même partie d'un fichier que le gestionnaire de versions ne sait pas réconcilier seul. Sur Salesforce, la plupart ne sont pas réels : c'est du bruit d'ordonnancement XML qu'un merge conscient des métadonnées devrait régler sans déranger personne. La vraie question porte sur les conflits qui survivent à ce filtre, et c'est le premier endroit d'un pipeline de livraison où l'IA justifie vraiment sa place.

Pourquoi Salesforce produit-il autant de conflits de fusion ?

Deux raisons structurelles, et ce n'est la faute de personne.

D'abord, les fichiers sont énormes. Un Profile décrit les permissions de toute l'org, donc deux développeurs travaillant sur deux objets sans rapport peuvent produire des modifications adjacentes dans un seul fichier. Profiles, permission sets, page layouts, pages Lightning et custom labels sont les suspects habituels.

Ensuite, l'ordre des éléments dans ces fichiers n'est pas stable. Récupérez deux fois le même Profile et les entrées de liste peuvent revenir dans un autre ordre. Git voit des lignes réordonnées et appelle cela un changement, même quand le sens des permissions est identique. C'est ainsi qu'une équipe passe un jeudi après-midi à résoudre un conflit qui n'existe pas.

Quelle différence entre un faux conflit et un vrai ?

Cette distinction est tout l'article, autant l'énoncer clairement.

• Faux conflit. Les deux branches ont modifié des choses différentes, seule la représentation textuelle se télescope. Deux développeurs ont chacun ajouté une permission de champ au même Profile. La bonne réponse est déterministe : garder les deux.
• Vrai conflit. Les deux branches ont modifié la même chose avec des valeurs différentes. L'une accorde l'accès en lecture à un champ, l'autre le retire. Aucun algorithme ne sait laquelle a raison, car la réponse est dans les tickets, pas dans le XML.

Traiter les deux comme un seul problème, voilà pourquoi l'outillage de conflits à mauvaise réputation. Il faut deux mécaniques distinctes.

Pourquoi le merge sémantique règle le premier et pas le second ?

Un merge conscient des métadonnées analyse le XML en éléments dotés de clés stables et fusionne élément par élément au lieu de ligne par ligne. Le merge driver Git pour Salesforce en open source illustre bien l'approche : il identifie des clés uniques dans les éléments de métadonnées, fusionne les entrées individuelles plutôt que des tableaux entiers, gère un réordonnancement déterministe pour les types réellement ordonnés comme les value sets de listes de sélection et les affectations de types d'enregistrement, et ne retombe sur un conflit brut que lorsqu'il ne reconnaît pas une clé. Les outils commerciaux font de même ; Gearset décrit un algorithme de merge sémantique conscient des métadonnées exactement pour cette raison.

Ce n'est pas de l'IA et cela ne doit pas l'être. C'est du parsing, et le parsing doit rester déterministe, rapide et ennuyeux. Bien fait, il élimine la grande majorité des conflits Salesforce avant qu'un humain les voie.

Ce qu'il ne peut pas faire, c'est décider. Quand les deux branches donnent à la même clé des valeurs différentes, un fusionneur déterministe correct refuse, et il a raison de refuser.

Où l'IA justifie-t-elle vraiment sa place dans un pipeline ?

Exactement là, sur ce refus. La résolution de conflits est un excellent premier travail pour l'IA en livraison, pour quatre raisons.

1. La tâche est bornée. Trois entrées connues : l'ancêtre commun, notre version, la leur. Aucune génération ouverte.
2. Le contexte qui tranche est lisible par machine. Le ticket, la description de la PR, les messages de commit et les métadonnées voisines disent quel changement était intentionnel.
3. La sortie est vérifiable. Une résolution proposée valide ou non contre l'org cible. C'est un vrai test, pas une impression.
4. C'est réversible. Une mauvaise réponse est attrapée en validation ou annulée, contrairement à un mauvais choix d'architecture qui part en production et se propage.

Comparez avec demander à un modèle d'écrire de l'Apex : entrée non bornée, contexte ambigu, vérification coûteuse. La résolution de conflits a la forme inverse, d'où l'intérêt de commencer par là.

À quoi ressemble une résolution IA sûre ?

1. Elle lit la sémantique des métadonnées, pas des lignes de texte. Si le modèle reçoit des marqueurs de conflit, le pipeline a déjà échoué une étape plus tôt.
2. Elle affiche l'ancêtre, notre version et la leur côte à côte, pour qu'un relecteur contrôle le raisonnement et pas seulement la conclusion.
3. Elle donne une raison, en citant le ticket ou le commit qui rend un côté intentionnel.
4. Elle valide le résultat fusionné contre l'org cible avant que la fusion n'atterrisse, pas après.
5. Elle exige une approbation humaine. Toujours, et surtout sur les métadonnées de permissions, où une fusion automatique silencieuse peut changer l'accès de chaque utilisateur rattaché à un Profile.
6. Elle écrit une piste d'audit : ce qui a été proposé, ce qui a été accepté, et par qui.

L'écosystème converge-t-il vers cela ?

Oui, et vite. Le DevOps Center de Salesforce propose désormais la résolution de conflits via des outils MCP, ou de grands modèles de langage analysent les conflits, les expliquent en langage naturel et suggèrent des solutions depuis l'IDE. Quand l'éditeur de la plateforme met l'analyse de conflits par LLM dans la boîte, le débat sur sa place dans un pipeline est clos.

Serpent aborde le sujet par le même angle. C'est le seul serveur MCP natif du DevOps Salesforce, avec resolve_metadata_conflict aux côtés de plan_deploy, create_pull_request et trigger_pipeline, si bien que la même résolution se pilote depuis Claude, Cursor, Windsurf ou Agentforce, avec contrôles préalables et approbation humaine obligatoire. La revue de code par IA tourne sur tous les plans, y compris le gratuit, parce que la revue et le conflit sont la même conversation sur le même changement.

FAQ

L'IA doit-elle fusionner automatiquement sans relecture ?

Non. Proposer et expliquer, puis exiger une approbation humaine, en particulier sur les Profiles et permission sets où une mauvaise fusion modifie l'accès de chaque utilisateur affecté.

Le merge sémantique rend-il l'IA inutile ?

Au contraire. Il élimine les faux conflits, donc il ne reste que les arbitrages ou du contexte supplémentaire aide.

Pourquoi les Profiles sont-ils les pires ?

Ce sont d'énormes fichiers uniques couvrant toute l'org, donc des travaux sans rapport atterrissent sur des lignes voisines, et l'ordre de leurs listes n'est pas garanti stable entre deux récupérations.

De quel contexte a besoin un résolveur IA ?

Le diff a trois voies, le ticket lié, les messages de commit et l'état de l'org cible. Sans cela, il devine avec plus d'assurance qu'un humain.

Comment savoir qu'une résolution était correcte ?

Validez le résultat fusionné contre l'org cible avant que la fusion n'atterrisse, et gardez une trace de ce qui a été proposé et approuvé.