
Tech • IA • Robotique • Jeu
Salesforce affirme que Claude Code l’a aidé à moderniser rapidement des logiciels hérités, à doubler la production effective de ses équipes d’ingénierie et à étendre l’usage d’agents autonomes à des milliers de développeurs, sans hausse correspondante du taux de bugs.
Une avancée majeure a consisté à convertir des applications Salesforce vieilles de plusieurs décennies pour qu’elles fonctionnent de façon plus headless et pilotée par API. Les dirigeants ont indiqué qu’un projet qui aurait normalement pris de six mois à un an a été mené en quelques semaines à quelques mois, portant la couverture API dans les clouds de l’entreprise à environ 80% à 90%. Cet effort a été notable, car une grande partie de la base de code était antérieure aux principes modernes de conception d’API et exigeait des changements dans des produits établis de longue date.
L’entreprise a déclaré que nombre des nouvelles applications et expériences utilisateur présentées à Dreamforce ont été construites avec un certain niveau d’intervention de Claude. Les équipes ont indiqué avoir livré en quelques semaines des travaux qui auraient auparavant pris des mois, transformant l’IA d’assistant de codage en multiplicateur de force pour la livraison produit. Ces gains ont été décrits non comme des expériences isolées, mais comme visibles dans des logiciels en production.
Plutôt que de compter les lignes de code, Salesforce a travaillé avec des chercheurs de Stanford sur une métrique appelée effective output, destinée à évaluer si le code généré par l’IA apporte des changements logiques significatifs ou crée de nouvelles fonctionnalités. Les ajouts de faible valeur, comme les commentaires, obtiennent un faible score, tandis qu’un travail fonctionnel substantiel obtient un score plus élevé. L’entreprise suit ensuite le dollar per effective output pour juger si l’usage de l’IA améliore matériellement la productivité, et a indiqué que cette mesure a progressé d’environ 2x.
Après une phase initiale d’usage ad hoc, l’entreprise a introduit une courbe de maturité des agents pour faire passer les ingénieurs au-delà de simples prompts vers des workflows plus structurés et autonomes. En un à deux mois, une grande part des ingénieurs est passée d’un usage basique à des niveaux plus avancés axés sur la planification, la décomposition, l’orchestration et l’exécution en parallèle. Le résultat, selon les dirigeants, a été une hausse nette de 2x de la production sans baisse équivalente de la qualité.
Des milliers d’employés utilisent désormais des agents de manière plus autonome dans l’ensemble du SDLC, notamment pour répondre à des tests échoués en CI/CD, corriger des problèmes et déclencher les étapes de revue de code et de fusion. Cette approche éloigne les ingénieurs du découpage manuel de chaque tâche en unités minuscules. À la place, des demandes de fonctionnalités plus larges sont confiées à des modèles ou à des couches d’orchestration qui décomposent le travail en tâches parallèles plus petites.
Les agents d’IA sont aussi utilisés en dehors du développement de fonctionnalités, en particulier dans la gestion des incidents. Dans un exemple, un agent a analysé un fil d’incident Slack, identifié qu’un service interne — et non le service externe d’astreinte — causait le problème, nommé l’équipe responsable et escaladé directement vers le bon contact. Le bénéfice rapporté était d’éviter la cascade habituelle où plusieurs équipes sont réveillées et doivent déterminer manuellement à qui appartient le problème.
L’expérimentation ascendante a été formalisée en une marketplace interne de “skills” d’agents, avec des outils d’évaluation pour tester si les workflows partagés améliorent réellement les résultats. Le système est relié à l’outillage d’ingénierie et permet la réutilisation à travers des milliers de dépôts, aidant les développeurs à travailler dans des bases de code qu’ils connaissent mal tout en produisant des pull requests de qualité. Les responsables ont décrit ce modèle comme favorisant d’abord l’innovation locale, puis l’extension de ce qui fait ses preuves.
Le principal garde-fou de l’entreprise est la validation. Les équipes définissent des critères objectifs de succès et d’échec, demandent aux agents de montrer des preuves pour les deux, puis mesurent les résultats à partir de données étiquetées de tickets et de pull requests déjà intégrées aux workflows d’ingénierie standard. Malgré un quasi-doublement du volume de code ces derniers mois, les dirigeants ont indiqué que les taux de bugs n’ont pas augmenté proportionnellement et étaient en moyenne plus faibles rapportés à la quantité de code générée.
L’un des principaux enseignements a été d’associer le modèle à la tâche. Les tâches simples ne justifient pas l’usage coûteux de grands modèles, alors que le débogage de longue haleine le justifie parfois. Dans un cas, un bug difficile dans un produit métier critique a résisté à des investigations humaines répétées; un grand modèle a été autorisé à déboguer, compiler et itérer pendant environ 24 heures avant de trouver une cause racine et de proposer un correctif, ensuite soumis à une validation stricte car un changement erroné aurait pu affecter les opérations financières des clients.
Salesforce considère les outils de codage par IA non comme une simple fonctionnalité de confort, mais comme un nouveau modèle opérationnel pour le développement logiciel et le support. Le véritable test est désormais de savoir si la vitesse, l’autonomie et l’échelle apportées par les agents peuvent continuer à produire des gains mesurables sans affaiblir la fiabilité.
Poser une question