GitHub élargit Copilot à plusieurs IA et lance Spark pour créer des applis web

GitHub veut faire de l’intelligence artificielle un élément plus souple du travail des développeurs. Le 4 novembre 2024, la plateforme de Microsoft met en avant une évolution importante de Copilot : son assistant de programmation n’est plus associé à une seule famille de modèles. En parallèle, GitHub dévoile Spark, un outil pensé pour transformer une idée exprimée en langage courant en point de départ d’une application web.

Ces annonces ne signifient pas que l’IA écrit seule des logiciels prêts à être mis en production. Elles illustrent plutôt un changement de méthode : le développeur peut déléguer une partie de la rédaction, de l’exploration et du prototypage à un assistant, tout en conservant la responsabilité de l’architecture, des tests, de la sécurité et des choix techniques. Avec Copilot, GitHub cherche désormais à offrir davantage de latitude dans le choix de l’IA employée pour cette assistance.

Copilot s’ouvre à Claude et Gemini

GitHub Copilot a d’abord été conçu autour des technologies d’OpenAI. Sa version initiale s’appuyait sur Codex, un modèle spécialisé dans le code issu de la famille GPT-3. En 2023, l’arrivée de Copilot Chat, utilisant notamment GPT-3.5 et GPT-4, a renforcé son rôle : l’outil ne se contentait plus de proposer la suite d’une ligne de code, il pouvait aussi répondre à des questions sur un projet, expliquer une fonction ou aider à corriger une erreur.

La nouveauté annoncée en novembre 2024 est le passage à une logique multi-modèles. Copilot doit pouvoir donner accès à Claude 3.5 Sonnet, développé par Anthropic, ainsi qu’à Gemini 1.5 Pro, conçu par Google, en plus des modèles d’OpenAI déjà mobilisés par le service.

Pour les utilisateurs, l’enjeu est moins de disposer d’un catalogue technologique que de pouvoir adapter l’assistant à une tâche. Un modèle peut formuler une explication plus claire sur un extrait de code, un autre être plus utile pour examiner une demande longue ou pour imaginer plusieurs pistes de résolution. GitHub présente ce choix élargi comme une manière de mieux répondre aux préférences individuelles et aux contraintes de chaque projet.

Thomas Dohmke, directeur général de GitHub, souligne ainsi l’importance de cette diversification. Pour GitHub, Copilot doit devenir un outil plus polyvalent, susceptible de s’adapter aux attentes d’équipes qui ne travaillent ni avec les mêmes langages, ni avec les mêmes méthodes, ni sur les mêmes types de produits.

Pourquoi le choix du modèle peut-il changer l’expérience de codage ?

Un grand modèle de langage est un système qui génère du texte en calculant, à partir d’un contexte, les réponses les plus plausibles. Lorsqu’il est appliqué au développement logiciel, ce texte peut prendre la forme de code, de commentaires, d’explications, de tests ou de commandes. Mais tous les modèles ne sont pas entraînés, réglés ou utilisés de la même façon.

Le passage au multi-modèles permet donc, en théorie, de mieux faire correspondre l’outil à l’intention de l’utilisateur. Un développeur peut vouloir une réponse concise pour débloquer une erreur, une explication pédagogique d’un morceau de code ancien, ou une première ébauche pour une fonctionnalité. Dans tous ces cas, le dialogue avec l’IA demeure un complément au travail humain, pas une garantie de qualité.

Cette ouverture a aussi une portée stratégique. Les assistants de code ont longtemps été associés à une relation privilégiée entre GitHub et OpenAI. En ajoutant les modèles d’Anthropic et de Google, GitHub adopte une position plus neutre sur le plan technologique : la valeur du service ne repose plus uniquement sur un modèle donné, mais sur l’intégration de plusieurs IA dans les outils utilisés au quotidien par les développeurs.

Cette prudence est particulièrement importante lorsqu’un assistant manipule du code lié à l’authentification, au paiement, à des données personnelles ou à des systèmes critiques. Plus l’IA accélère la production d’extraits de code, plus les équipes doivent veiller à ce que leurs pratiques de validation suivent le rythme.

GitHub Spark veut rapprocher l’idée de l’application web

L’autre annonce majeure concerne GitHub Spark. Cet outil est présenté comme une nouvelle façon de créer des applications web à partir d’instructions rédigées en langage naturel. Au lieu de commencer par installer un environnement de développement, choisir une structure de projet puis écrire les premières pages et interactions, l’utilisateur décrit l’objectif qu’il souhaite atteindre.

Le principe répond à une frustration répandue : réaliser un prototype web peut exiger de nombreuses étapes avant même de savoir si l’idée est pertinente. Il faut souvent penser à l’interface, aux composants, à la logique, aux données et à l’organisation générale du projet. Spark ambitionne d’alléger cette phase initiale afin de permettre une itération plus rapide.

Pour une équipe produit, cela peut faciliter la communication entre les personnes qui imaginent un service et celles qui le construisent. Une consigne en langage naturel sert alors de point de départ commun. Pour un développeur, Spark peut aider à matérialiser rapidement une piste, puis à l’améliorer ou à la remettre en question. Pour une personne moins technique, il peut rendre plus tangible une idée qui, auparavant, serait restée décrite dans un document ou une maquette.

Il faut toutefois distinguer prototyper et livrer un produit complet. Une application destinée à un usage réel exige toujours des décisions précises : gestion des accès, protection des données, fiabilité, performances, maintenance et conformité aux règles applicables. L’intérêt de Spark se situe d’abord dans la réduction de la distance entre une intention et une première version concrète.

Que permet l’intégration de Copilot dans Xcode ?

GitHub étend aussi Copilot à Xcode, l’environnement de développement utilisé pour concevoir des applications destinées aux plateformes d’Apple. Cette intégration vise les développeurs travaillant notamment avec Swift et Objective-C, deux langages essentiels pour les applications iOS et macOS.

L’idée est simple : l’assistance doit apparaître là où le code est écrit, sans obliger le développeur à changer constamment d’outil. Copilot peut ainsi fournir des suggestions en temps réel et accompagner la rédaction du code depuis l’environnement de travail habituel des équipes Apple.

L’arrivée dans Xcode s’inscrit dans une stratégie d’élargissement. GitHub ne cherche pas seulement à enrichir son assistant conversationnel, mais à placer l’IA au plus près des gestes quotidiens du développement : écrire une fonction, comprendre un message d’erreur, explorer une base de code ou préparer une première version d’une fonctionnalité.

Une promesse de productivité, avec des limites concrètes

L’argument de la productivité est central dans ces évolutions. Les outils d’IA peuvent faire gagner du temps sur les tâches répétitives : écrire une structure de base, commenter un extrait, générer une fonction simple, reformuler une requête technique ou produire des exemples de tests. Ce temps peut ensuite être consacré à des problèmes plus difficiles, comme la compréhension des besoins utilisateurs ou la conception d’une architecture robuste.

Mais la productivité ne se mesure pas seulement à la vitesse de frappe. Une réponse générée trop vite et mal vérifiée peut créer une dette technique : code incompréhensible, duplications, comportements inattendus ou vulnérabilités. L’assistance est donc utile lorsqu’elle s’insère dans un processus rigoureux, avec des tests et une revue par des pairs.

Les équipes devront aussi apprendre à formuler de bonnes demandes. Donner un contexte clair, préciser les contraintes, demander des explications et vérifier les hypothèses conduit généralement à des résultats plus exploitables qu’une instruction vague. Ce savoir-faire, souvent appelé formulation de requêtes ou « prompt », devient une compétence complémentaire, sans remplacer la maîtrise des fondamentaux du logiciel.

Enfin, le choix entre plusieurs modèles peut accroître la flexibilité, mais aussi la complexité. Les organisations devront déterminer quels usages sont autorisés, quelles données peuvent être partagées avec un assistant, et comment documenter l’emploi de l’IA dans leurs projets. La question est particulièrement sensible pour les entreprises qui manipulent du code propriétaire ou des informations confidentielles.

Ce qu’il faut surveiller dans les prochains mois

L’ouverture de Copilot à Claude 3.5 Sonnet et Gemini 1.5 Pro, l’arrivée de Spark et l’intégration dans Xcode dessinent une même orientation : GitHub veut faire de l’IA une couche de travail présente à chaque étape du développement logiciel. La création d’applications pourrait progressivement se déplacer vers un échange plus direct entre une intention exprimée en langage naturel et une première implémentation technique.

La véritable mesure de cette évolution ne sera pas seulement la qualité apparente des démonstrations. Il faudra observer la disponibilité effective des modèles et des fonctions selon les offres, la capacité des équipes à contrôler le code produit, ainsi que la qualité des applications issues de ces nouveaux outils. Spark devra notamment démontrer qu’il peut être utile au-delà de la simple démonstration de prototype.

Pour les développeurs, la question n’est donc pas de savoir si l’IA remplacera la programmation. Elle est de comprendre comment ces assistants peuvent enlever une part du travail répétitif sans affaiblir les exigences de qualité. Dans cette perspective, le multi-modèles de Copilot et l’approche conversationnelle de Spark sont moins une fin en soi qu’une nouvelle étape dans l’évolution des outils de création logicielle.