Resolution de conflits par IA sur les pull requests Salesforce

En bref : un conflit de fusion, ce sont deux modifications concurrentes de la meme partie d'un fichier que le gestionnaire de versions ne sait pas reconcilier seul. Sur Salesforce, la plupart ne sont pas reels : c'est du bruit d'ordonnancement XML qu'un merge conscient des metadonnees devrait regler sans deranger personne. La vraie question porte sur les conflits qui survivent a ce filtre, et c'est le premier endroit d'un pipeline de livraison ou 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 enormes. Un Profile decrit les permissions de toute l'org, donc deux developpeurs 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 elements dans ces fichiers n'est pas stable. Recuperez deux fois le meme Profile et les entrees de liste peuvent revenir dans un autre ordre. Git voit des lignes reordonnees et appelle cela un changement, meme quand le sens des permissions est identique. C'est ainsi qu'une equipe passe un jeudi apres-midi a resoudre un conflit qui n'existe pas.

Quelle difference entre un faux conflit et un vrai ?

Cette distinction est tout l'article, autant l'enoncer clairement.

• Faux conflit. Les deux branches ont modifie des choses differentes, seule la representation textuelle se telescope. Deux developpeurs ont chacun ajoute une permission de champ au meme Profile. La bonne reponse est deterministe : garder les deux.
• Vrai conflit. Les deux branches ont modifie la meme chose avec des valeurs differentes. L'une accorde l'acces en lecture a un champ, l'autre le retire. Aucun algorithme ne sait laquelle a raison, car la reponse est dans les tickets, pas dans le XML.

Traiter les deux comme un seul probleme, voila pourquoi l'outillage de conflits a mauvaise reputation. Il faut deux mecaniques distinctes.

Pourquoi le merge semantique regle le premier et pas le second ?

Un merge conscient des metadonnees analyse le XML en elements dotes de cles stables et fusionne element par element au lieu de ligne par ligne. Le merge driver Git pour Salesforce en open source illustre bien l'approche : il identifie des cles uniques dans les elements de metadonnees, fusionne les entrees individuelles plutot que des tableaux entiers, gere un reordonnancement deterministe pour les types reellement ordonnes comme les value sets de listes de selection et les affectations de types d'enregistrement, et ne retombe sur un conflit brut que lorsqu'il ne reconnait pas une cle. Les outils commerciaux font de meme ; Gearset decrit un algorithme de merge semantique conscient des metadonnees exactement pour cette raison.

Ce n'est pas de l'IA et cela ne doit pas l'etre. C'est du parsing, et le parsing doit rester deterministe, rapide et ennuyeux. Bien fait, il elimine la grande majorite des conflits Salesforce avant qu'un humain les voie.

Ce qu'il ne peut pas faire, c'est decider. Quand les deux branches donnent a la meme cle des valeurs differentes, un fusionneur deterministe correct refuse, et il a raison de refuser.

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

Exactement la, sur ce refus. La resolution de conflits est un excellent premier travail pour l'IA en livraison, pour quatre raisons.

1. La tache est bornee. Trois entrees connues : l'ancetre commun, notre version, la leur. Aucune generation ouverte.
2. Le contexte qui tranche est lisible par machine. Le ticket, la description de la PR, les messages de commit et les metadonnees voisines disent quel changement etait intentionnel.
3. La sortie est verifiable. Une resolution proposee valide ou non contre l'org cible. C'est un vrai test, pas une impression.
4. C'est reversible. Une mauvaise reponse est attrapee en validation ou annulee, contrairement a un mauvais choix d'architecture qui part en production et se propage.

Comparez avec demander a un modele d'ecrire de l'Apex : entree non bornee, contexte ambigu, verification couteuse. La resolution de conflits a la forme inverse, d'ou l'interet de commencer par la.

A quoi ressemble une resolution IA sure ?

1. Elle lit la semantique des metadonnees, pas des lignes de texte. Si le modele recoit des marqueurs de conflit, le pipeline a deja echoue une etape plus tot.
2. Elle affiche l'ancetre, notre version et la leur cote a cote, pour qu'un relecteur controle le raisonnement et pas seulement la conclusion.
3. Elle donne une raison, en citant le ticket ou le commit qui rend un cote intentionnel.
4. Elle valide le resultat fusionne contre l'org cible avant que la fusion n'atterrisse, pas apres.
5. Elle exige une approbation humaine. Toujours, et surtout sur les metadonnees de permissions, ou une fusion automatique silencieuse peut changer l'acces de chaque utilisateur rattache a un Profile.
6. Elle ecrit une piste d'audit : ce qui a ete propose, ce qui a ete accepte, et par qui.

L'ecosysteme converge-t-il vers cela ?

Oui, et vite. Le DevOps Center de Salesforce propose desormais la resolution de conflits via des outils MCP, ou de grands modeles de langage analysent les conflits, les expliquent en langage naturel et suggerent des solutions depuis l'IDE. Quand l'editeur de la plateforme met l'analyse de conflits par LLM dans la boite, le debat sur sa place dans un pipeline est clos.

Serpent aborde le sujet par le meme angle. C'est le seul serveur MCP natif du DevOps Salesforce, avec resolve_metadata_conflict aux cotes de plan_deploy, create_pull_request et trigger_pipeline, si bien que la meme resolution se pilote depuis Claude, Cursor, Windsurf ou Agentforce, avec controles prealables 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 meme conversation sur le meme 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 ou une mauvaise fusion modifie l'acces de chaque utilisateur affecte.

Le merge semantique rend-il l'IA inutile ?

Au contraire. Il elimine les faux conflits, donc il ne reste que les arbitrages ou du contexte supplementaire aide.

Pourquoi les Profiles sont-ils les pires ?

Ce sont d'enormes 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 recuperations.

De quel contexte a besoin un resolveur IA ?

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

Comment savoir qu'une resolution etait correcte ?

Validez le resultat fusionne contre l'org cible avant que la fusion n'atterrisse, et gardez une trace de ce qui a ete propose et approuve.