Code review : pré­sen­ta­tion des méthodes et outils

La code review fait partie in­té­grante du dé­ve­lop­pe­ment moderne de logiciels. La révision du code par plusieurs membres d’une même équipe de pro­gram­ma­tion permet d’en détecter les erreurs et contribue à en améliorer la qualité. Vous pouvez utiliser dif­fé­rentes tech­niques et méthodes à cet effet ; retrouvez ci-dessous des ex­pli­ca­tions dé­tail­lées les con­cer­nant.

La code review, ou « revue de code », cor­res­pond à une mesure d’assurance qualité dans le domaine du dé­ve­lop­pe­ment de logiciels. Le code source constitue l’élément de base du travail de dé­ve­lop­pe­ment, mais aussi le principal produit de la pro­gram­ma­tion. Il convient donc de toujours soumettre le code que vous venez de créer ou de modifier à une code review. Cette procédure consiste à laisser un ou plusieurs membres de l’équipe vérifier le travail effectué par un pro­gram­meur.

Un projet logiciel comprend une « base de code », c’est-à-dire une col­lec­tion de fichiers de code qui per­met­tent, une fois ras­sem­blés, de livrer un produit. En plus du code du produit à pro­pre­ment parler, cette base comprend, entre autres, la con­fi­gu­ra­tion, les outils de dé­ve­lop­pe­ment et les tests né­ces­saires, tous ces éléments étant présentés sous forme de code. L’ensemble de la base de code est géré à l’aide d’un système de contrôle de version, comme Git. Dif­fé­rentes « branches » per­met­tent de gérer plusieurs versions de la base de code pa­ral­lè­le­ment les unes aux autres. Il est donc possible de dé­ve­lop­per de nouvelles fonc­tion­na­li­tés sans pour autant modifier la version de pro­duc­tion de la base de code.

Gé­né­ra­le­ment, le travail de dé­ve­lop­pe­ment est donc effectué sur des branches de fonc­tion­na­li­tés, intégrées de manière pé­rio­dique à la branche prin­ci­pale. La révision du code in­ter­vient avant la « fusion », c’est-à-dire avant l’as­so­cia­tion du code nou­vel­le­ment créé ou modifié avec la base de code existante. Celle-ci a pour but de repérer et d’éliminer les erreurs assez tôt dans le processus, avant la mise en pro­duc­tion du code.

La révision du code ne sert toutefois pas uni­que­ment à résoudre les éventuels bogues. Le bon fonc­tion­ne­ment du code, sans erreur et avec la pro­duc­tion du résultat souhaité, ne constitue en effet que l’un des prérequis. Il existe de nombreux autres critères de qualité à respecter pour obtenir un « clean code ». La présence de com­men­taires, la clarté et la cohérence du code, mais aussi le respect d’un certain guide de style et la capacité d’in­té­gra­tion à des systèmes existants cons­ti­tuent d’ailleurs autant de pa­ra­mètres es­sen­tiels qu’il convient de prendre en compte lors de la code review.

Comme le travail de dé­ve­lop­pe­ment est souvent effectué en groupe, la code review ne se contente pas d’améliorer la qualité du code. La révision du code est en effet assurée par d’autres membres de l’équipe de dé­ve­lop­pe­ment, avec des effets sociaux : les nouveaux membres bé­né­fi­cient de com­men­taires sur les con­ven­tions et les bonnes pratiques, et les con­nais­sances sont mieux échangées et trans­mises au sein de l’or­ga­ni­sa­tion. La revue de code contribue donc à favoriser une certaine culture de la qualité.

De nos jours, même si la revue de code est assurée par des personnes, les processus de code review s’appuient gé­né­ra­le­ment sur des outils spé­ci­fiques. Les outils de code review sont efficaces et soulagent toutes les personnes con­cer­nées, qui n’ont plus besoin de gérer la coor­di­na­tion complexe et fas­ti­dieuse des processus. Elles peuvent donc se consacrer plei­ne­ment à la code review pro­pre­ment dite.

Sur le plan con­cep­tuel, la code review réalisée par des personnes se situe à mi-chemin entre deux méthodes d’analyse au­to­ma­ti­sées : l’analyse statique et l’analyse dynamique. Voici ce qui les dif­fé­ren­cie les unes des autres :

Le concept d’une code review est plutôt simple : un ou plusieurs membres d’une équipe de dé­ve­lop­pe­ment (les « réviseurs ») examinent le code nou­vel­le­ment créé ou modifié afin de vérifier que celui-ci est correct. Les réviseurs lisent le code et iden­ti­fient toute erreur po­ten­tielle, ainsi que toute di­ver­gence par rapport aux con­ven­tions en place au sein de l’équipe. Les réviseurs peuvent di­rec­te­ment apporter des amé­lio­ra­tions au code ou trans­mettre leurs con­clu­sions aux auteurs d’origine, qui s’occupent alors d’intégrer les mo­di­fi­ca­tions.

L’idée peut paraitre simple, mais en pratique, le travail lié aux processus de code review peut ra­pi­de­ment prendre de l’ampleur. En effet, le diable est dans les détails : quelles mo­di­fi­ca­tions vont de pair et comment celles-ci sont-elles com­mu­ni­quées aux réviseurs ? Comment signaler les erreurs détectées et laisser des com­men­taires aux em­pla­ce­ments cor­res­pon­dants dans le code et mettre ces derniers à dis­po­si­tion des personnes chargées de l’amé­lio­ra­tion du code ? De telles actions ne peuvent être coor­don­nées que si votre équipe est très petite ou si vous disposez d’outils de code review.

Dans les équipes de pro­gram­ma­tion dis­tri­buées et agiles, la code review fait le plus souvent du processus de dé­ve­lop­pe­ment. Dans le cadre de l’in­té­gra­tion continue (IC), le code est écrit, testé et intégré à la base de code existante de façon continue. La code review assurée par une personne fait alors partie du « pipeline » au­to­ma­tisé de l’IC emprunté par toutes les unités de code. Si le code réussit tous les tests, il est fi­na­le­ment intégré aux systèmes de pro­duc­tion et diffusé par l’in­ter­mé­diaire de ces derniers.

Découvrez avec nous les dif­fé­rentes sections du pipeline d’IC et l’em­pla­ce­ment occupé par la code review dans ce dernier :

1. Écrire du code
   1. Écrire du code sur la branche de fonc­tion­na­lité
   2. Tester le code au sein de l’en­vi­ron­ne­ment local
       
2. Intégrer le code à la base de code
   1. Analyser et formater le code de façon au­to­ma­ti­sée sur la branche de fonc­tion­na­lité
   2. Effectuer une code review et im­plé­men­ter les amé­lio­ra­tions né­ces­saires
   3. Fusionner le code avec celui de la branche prin­ci­pale
   4. Déployer et tester la branche prin­ci­pale sur un site de staging
       
3. Produire le code
   1. Fusionner le code avec celui de la branche de pu­bli­ca­tion
   2. Déployer la branche de pu­bli­ca­tion sur le site actif

La code review constitue une étape in­dis­pen­sable du contrôle de la qualité dans le domaine du dé­ve­lop­pe­ment de logiciels. La revue de code sert en effet à vérifier que le code nou­vel­le­ment créé est aussi ir­ré­pro­chable que possible et qu’il répond bien aux normes de qualité en vigueur dans l’or­ga­ni­sa­tion. Il permet, à long terme, de réduire la dette technique et, à plus court terme, d’éviter l’exécution d’un code erroné sur les systèmes de pro­duc­tion.

Le code est un outil puissant ; une fois écrit, un même code peut en effet s’exécuter de façon répétée ou si­mul­ta­née en tant qu’instances multiples. Toute erreur entraîne donc des ré­per­cus­sions, et une petite faute commise à un em­pla­ce­ment central peut donc avoir d’im­por­tantes con­sé­quences pour l’ensemble du système. C’est la raison pour laquelle la cor­rec­tion d’erreurs dans le code déjà en cours d’exécution dans un système de pro­duc­tion coûte gé­né­ra­le­ment plus cher qu’une cor­rec­tion en amont.

La code review favorise l’éga­li­sa­tion des dif­fé­rences de qualité entre tous les éléments qui cons­ti­tuent la base de code. En effet, la qualité du code peut fortement varier en fonction des cir­cons­tances qui pré­do­mi­nent lors de son écriture. Les pa­ra­mètres suivants sont tous sus­cep­tibles d’amoindrir la qualité du code développé par un pro­gram­meur :

• Manque d’ex­pé­rience en termes de pro­gram­ma­tion
• Faible maîtrise du système
• Con­nais­sance limitée des con­ven­tions ap­pli­quées par l’équipe
• Stress ressenti lors du dé­ve­lop­pe­ment
• Dé­ve­lop­pe­ment effectué avec des con­traintes de temps
• Épui­se­ment mental

Aujourd’hui, l’uti­li­sa­tion du code ne se limite plus à l’écriture de pro­grammes. Le code est en effet un outil d’ex­pres­sion qui se prête bien à la des­crip­tion précise de toutes sortes de systèmes. Il peut, entre autres, être utilisé pour la rédaction de contrats in­tel­li­gents basés sur la blo­ck­chain ou la dé­fi­ni­tion d’en­vi­ron­ne­ments Cloud par IaC (In­fras­truc­ture as Code). Pour toutes ces approches, une code review peut également s’avérer utile.

Nous vous pré­sen­tons ici les bonnes pratiques issues d’une étude empirique menée à grande échelle par une équipe de pro­gram­meurs de l’en­tre­prise Cisco, par l’in­ter­mé­diaire de la société SmartBear. Ces bonnes pratiques tiennent notamment compte des limites des réviseurs humains. Le code est un outil complexe, et sa révision requiert la plus grande attention. Or, les capacités mentales des êtres humains restent limitées et finissent par faiblir lorsqu’elles sont sol­li­ci­tées de manière continue. En cas d’inat­ten­tion, des erreurs peuvent fa­ci­le­ment passer au travers des mailles du filet, ce qui revient à gaspiller le temps consacré à la code review.

Ces bonnes pratiques visent en outre à garantir l’ef­fi­ca­cité des processus de code review. Si des erreurs sont détectées, il convient de les corriger. Pour ce faire, il faut disposer de com­pé­tences claires et de la pos­si­bi­lité de contrôler les processus, ainsi que de suivre leur avancée. Nous listons ci-dessous quelques-unes des bonnes pratiques que nous avons iden­ti­fiées :

• Un maximum de 400 lignes de code par session : plus le volume de code est important et plus les erreurs sont sus­cep­tibles de passer ina­per­çues.
   
• Une révision limitée à 500 lignes de code par heure : au-delà, la capacité des réviseurs à iden­ti­fier d’éven­tuelles erreurs s’en trouve amoindrie.
   
• Une code review limitée à 60 minutes : si la code review dure plus longtemps, les réviseurs risquent de perdre en con­cen­tra­tion.
   
• La dé­fi­ni­tion d’objectifs et l’en­re­gis­tre­ment de certaines mesures : quel est le nombre d’erreurs trouvées par unité de temps ou par ligne de code ?
   
• L’an­no­ta­tion du code source par ses auteurs avant toute révision : ces an­no­ta­tions aident les réviseurs à vérifier et à com­prendre les mo­di­fi­ca­tions du code.
   
• L’uti­li­sa­tion de listes de contrôle : celles-ci devraient énumérer les points à garder en mémoire lors de chaque révision.
   
• La mise en place d’un processus pour la cor­rec­tion des erreurs iden­ti­fiées : il ne suffit pas de repérer les erreurs. Pour les corriger, il convient de mettre en place des règles et des struc­tures claires.
   
• La promotion des aspects positifs d’une culture de la code review : une erreur ne doit pas être vue comme une faute per­son­nelle, mais plutôt comme une occasion d’ap­pren­tis­sage.
   
• L’ex­ploi­ta­tion des im­pli­ca­tions sub­cons­cientes liées à l’examen par les pairs : les pro­gram­meurs sont plus sus­cep­tibles de faire des efforts s’ils savent que leur code est ensuite soumis à une révision.
   
• La mise en place de processus de code review légers : les outils de code review modernes ont amélioré l’ef­fi­ca­cité de la revue de code.

De manière générale, la code review est con­si­dé­rée comme es­sen­tielle dans le cadre du dé­ve­lop­pe­ment de logiciels ; les avantages que comporte la revue de code sont d’ailleurs évidents. Son uti­li­sa­tion n’est toutefois pas dénuée d’in­con­vé­nients. Découvrez avec nous les avantages et les in­con­vé­nients de la revue de code.

Le principal avantage de la revue de code tient au fait qu’elle permet d’iden­ti­fier et d’éliminer les erreurs en amont, avant que celles-ci n’aient de con­sé­quences négatives. Cette méthode s’avère bien plus efficace que l’iden­ti­fi­ca­tion et la cor­rec­tion d’erreurs à une étape ul­té­rieure dans le cycle de vie du code. Si le code erroné est déjà intégré à un système de pro­duc­tion, d’autres éléments de ce dernier peuvent dépendre de ce code, rendant ainsi les amé­lio­ra­tions plus dif­fi­ciles.

Les code reviews ré­gu­lières ne servent toutefois pas uni­que­ment à re­cher­cher les erreurs isolées. Il convient notamment d’analyser la « vue d’ensemble » : comment le code s’intègre-t-il à la base de code ? Une code review continue peut permettre l’iden­ti­fi­ca­tion de modèles généraux et la dé­fi­ni­tion de certaines normes. Les codes smells sont ainsi iden­ti­fiés et résolus au même titre que les erreurs fonc­tion­nelles. Le cas échéant, il est possible de recourir au réusinage de code et aux patrons de con­cep­tion afin d’uni­for­mi­ser plusieurs com­po­sants.

Tous les membres d’une équipe de pro­gram­ma­tion sont impliqués dans le processus de code review, ce qui les amène à com­mu­ni­quer. Sans surprise, les stra­té­gies de code review bien établies con­tri­buent donc à l’amé­lio­ra­tion des com­pé­tences de l’équipe concernée en matière de code. Les processus de code review per­met­tent d’intégrer et de diffuser les con­nais­sances au sein d’une équipe, et donc d’améliorer les com­pé­tences de chaque membre en matière de code.

Au niveau d’une or­ga­ni­sa­tion, les code reviews par­ti­ci­pent au dé­ve­lop­pe­ment d’une culture axée sur la qualité. Les personnes qui savent que leur travail fait l’objet d’une révision ont tendance à fournir davantage d’efforts. Une code review d’environ un tiers du code produit suffit à obtenir des retombées positives.

Bien entendu, la mise en place d’une code review dans une or­ga­ni­sa­tion re­pré­sente du travail. La revue de code est chro­no­phage et mobilise du personnel ; la gestion des processus concernés nécessite en outre de mobiliser des res­sources. Ces coûts per­met­tent toutefois d’améliorer la qualité du code ; en effet, n’oubliez pas qu’un code de mauvaise qualité peut lui aussi engendrer des frais con­si­dé­rables.

Sans outils de code review, la revue de code peut s’avérer par­ti­cu­liè­re­ment inef­fi­cace. Avant l’avènement de la code review légère, les méthodes tra­di­tion­nelles ont tout par­ti­cu­liè­re­ment posé problème. Quel que soit le cas, il est essentiel d’établir des avec précision les objectifs et les exigences en lien avec les processus de code review ; cela permet de mieux calculer le rapport coûts-avantages et d’éviter toute in­cer­ti­tude.

Pour ce qui est des dé­ve­lop­peurs, les code reviews ont tout pour leur permettre de renforcer leurs con­nais­sances et améliorer leur cohésion d’équipe. Pour ce faire, il est pri­mor­dial de créer un en­vi­ron­ne­ment de travail cons­truc­tif et collégial. Dans le cadre d’une code review une attitude hostile ou pleine de reproches peut tout à fait trau­ma­ti­ser les personnes con­cer­nées. Les nouveaux membres d’une équipe, les personnes ap­par­te­nant à une minorité et les pro­gram­meurs disposant d’une ex­pé­rience re­la­ti­ve­ment limitée risquent tout par­ti­cu­liè­re­ment d’être touchés par ce phénomène.

L’« ins­pec­tion Fagan » est con­si­dé­rée comme la première forme de code review. Ce processus coûteux mo­bi­li­sait quatre personnes et né­ces­si­tait de nom­breuses réunions, ainsi que l’im­pres­sion du code à vérifier sur papier. Très efficace en termes de détection des erreurs, l’ins­pec­tion Fagan est une méthode im­pos­sible à intégrer au travail de dé­ve­lop­pe­ment moderne, dans toute son agilité.

Pa­ral­lè­le­ment aux lourdeurs de l’ins­pec­tion Fagan, il est aujourd’hui possible de recourir à des approches plus légères en matière de code review. Elles supposent toutes la par­ti­ci­pa­tion de l’auteur (ou des auteurs) du code, ainsi que d’un ou de plusieurs réviseurs.

La méthode d’analyse par-dessus l’épaule constitue la forme de code review la plus simple. L’auteur présente le code écrit à un autre membre de l’équipe de dé­ve­lop­pe­ment (faisant office de réviseur). Celui-ci recherche toute erreur éven­tuelle, et cette méthode permet également de discuter de la structure du code ainsi que des autres approches en­vi­sa­geables. Comme l’auteur et le réviseur sont en com­mu­ni­ca­tion directe, l’échange de com­men­taires est rapide et les amé­lio­ra­tions peuvent faire l’objet d’une in­té­gra­tion immédiate.

La code review par-dessus l’épaule s’effectue in situ, sur l’or­di­na­teur de l’auteur. Le réviseur regarde par-dessus son épaule le code qu’il lui présente. Cette technique permet d’utiliser l’ensemble des res­sources et des outils dis­po­nibles sur la machine de dé­ve­lop­pe­ment. La code review brille par sa sim­pli­cité et peut fa­ci­le­ment s’organiser de façon ponc­tuelle.

Sur le plan con­cep­tuel, la revue de code par pair pro­gram­ming ressemble à la code review par-dessus l’épaule. En effet, cette méthode requiert elle aussi les com­pé­tences de deux membres de l’équipe de pro­gram­ma­tion. Ces deux stra­té­gies diffèrent toutefois en termes de chro­no­lo­gie des processus de création et de révision du code. La code review par-dessus l’épaule in­ter­vient après la création du code, alors que dans la pro­gram­ma­tion en binôme, les étapes de mise au point et de révision ne font qu’une.

Dans le cadre de la pro­gram­ma­tion en binôme, un « pilote » écrit le code et se charge des détails liés à son im­plé­men­ta­tion. Le réviseur, quant à lui, supervise l’écriture du code et formule des com­men­taires. Il garde également à l’esprit la vue d’ensemble ; non seulement le code ne doit pas contenir de fautes et fonc­tion­ner de façon autonome, mais il doit aussi respecter les modèles et les règles qui s’ap­pli­quent à l’in­té­gra­lité du projet.

Il est essentiel que le pilote et le réviseur in­ter­ver­tis­sent les rôles ré­gu­liè­re­ment. Cela leur permet en effet de changer de pers­pec­tive, mais aussi d’équi­li­brer les rapports de force et de se res­sour­cer men­ta­le­ment. Les membres les moins ex­pé­ri­men­tés de l’équipe peuvent aussi en profiter pour découvrir ces deux rôles.

Pour modifier ou ajouter du code dans le cadre de projets d’envergure, il est souvent né­ces­saire de charger plusieurs personnes de la révision du code. La no­ti­fi­ca­tion par email pour la code review consiste à envoyer un ré­ca­pi­tu­la­tif des mo­di­fi­ca­tions à toutes les personnes con­cer­nées. Les no­ti­fi­ca­tions par email se succèdent ensuite, et les mo­di­fi­ca­tions sont intégrées jusqu’à ce que la révision soit terminée et que le code soit finalisé.

Comme vous l’imaginez, ce processus peut ra­pi­de­ment être à l’origine d’une certaine confusion si les par­ti­ci­pants sont trop nombreux. La no­ti­fi­ca­tion par email pour la code review est d’ailleurs plus efficace si elle est associée à l’uti­li­sa­tion d’outils de code review ap­pro­priés.

Les approches modernes en matière de code review sont basées sur des outils de code review spé­ci­fiques. Ils per­met­tent de struc­tu­rer les processus de révision, ga­ran­tis­sent leur ef­fi­ca­cité et en­re­gistrent certaines mesures. Grâce à ces outils, le processus de révision peut être planifié, contrôlé et vérifié.

Dif­fé­rents outils de code review sont dis­po­nibles. Ceux-ci sont parfois intégrés dans des stra­té­gies exis­tantes en lien avec l’in­té­gra­tion ou la livraison continue (IC/LC). Découvrez avec nous les dif­fé­rents types d’outils dis­po­nibles, ainsi que des exemples.

Les outils de code review ont pour base les systèmes de contrôle de version dis­tri­bués (« Dis­tri­bu­ted version control systems », ou DVCS), notamment le très populaire logiciel Git. Ceux-ci per­met­tent de suivre les mo­di­fi­ca­tions du code et de les afficher sous la forme de « diffs ». Les pla­te­formes basées sur Git comme GitHub et GitLab amé­lio­rent la pré­sen­ta­tion et mettent avant tout en avant le travail d’équipe. Grâce à leurs demandes de fusion, ces pla­te­formes proposent une code review intégrée avant toute ac­cep­ta­tion d’un nouveau code.

Ces outils s’appuient sur Git ou d’autres systèmes de contrôle de version dis­tri­bués (DVCS). À partir de là, ils utilisent gé­né­ra­le­ment une interface uti­li­sa­teur basée sur le Web afin d’organiser des code reviews en équipe. Plusieurs outils de code review proposent également leur propre interface de ligne de commande (« Command line interface », CLI).

GitHub est con­si­dé­rée comme la pla­te­forme standard pour la gestion des ré­fé­ren­tiels Git basée sur le Web. Pour la code review, le mécanisme pré­do­mi­nant est celui des « pull requests ». Pour apporter des mo­di­fi­ca­tions au code d’un ré­fé­ren­tiel, il suffit de suivre un schéma simple :

1. Cloner le ré­fé­ren­tiel en tant que copie locale.
2. Effectuer les mo­di­fi­ca­tions dans la branche concernée.
3. Créer une « pull request » : il s’agit de demander au chargé de main­te­nance du ré­fé­ren­tiel de vérifier les mo­di­fi­ca­tions et, en cas d’éva­lua­tion con­cluante, de fusionner celles-ci avec le ré­fé­ren­tiel principal.

L’outil de code review Review Board donne la priorité aux demandes de révision. Avec son interface Web moderne et con­vi­viale, il propose une vue d’ensemble de toutes les demandes de révision en cours sur les ré­fé­ren­tiels et les branches. La commande « rbt » garantit un accès rapide à partir de la ligne de commande. En plus du code, il est possible d’intégrer des gra­phiques et des documents PDF aux processus de révision.

Installée sur un serveur dédié, Gerrit agit comme une interface entre les mo­di­fi­ca­tions apportées au code et la base de code de pro­duc­tion. Les mo­di­fi­ca­tions sont vérifiées par code review et doivent être acceptées avant de passer en pro­duc­tion. Une ins­tal­la­tion Gerrit est cons­ti­tuée d’un en­vi­ron­ne­ment Git au­to­hé­bergé avec un accès SSH, mais aussi d’une interface Web dis­po­nible par HTTPS. En plus de no­ti­fi­ca­tions op­tion­nelles par email ; Gerrit propose un système de vote relatif aux mo­di­fi­ca­tions du code.

Développé par SmartBear, l’outil de code review Code Col­la­bo­ra­tor met plutôt l’accent sur les récits uti­li­sa­teur, c’est-à-dire de spé­ci­fi­ca­tions de fonc­tion­na­li­tés centrées sur les uti­li­sa­teurs, trans­po­sées en code puis validées par des tests. En plus de l’équipe de pro­gram­ma­tion, cet outil étend la par­ti­ci­pa­tion aux res­pon­sables et aux équipes de test et permet de vérifier de façon cohérente les mo­di­fi­ca­tions apportées aux récits uti­li­sa­teur, au code et aux plans de test.

Connus sous le nom de « linters », ces outils servent à analyser et à formater le code de manière au­to­ma­ti­sée, et donc à le préparer pour une code review. Sur le plan technique, cette analyse reste statique. En effet, si le code est lu, il n’est pas exécuté. Les linters sont utilisés dans le cadre du pipeline d’IC, de manière à uni­for­mi­ser le formatage du code ou encore à adapter le code par rapport au guide de style.

L’analyse statique renvoie aussi des mesures relatives au code, comme le nombre de lignes de code (« Lines of code » ou LOC) par fichier, par classe ou par fonction. Les linters sont également capables de détecter les erreurs les plus fré­quentes avant la révision du code par des êtres humains. Il peut par exemple s’agir d’erreurs de type, d’in­jec­tions SQL et d’erreurs hors limites.

Sur le plan con­cep­tuel, ces outils re­la­ti­ve­ment récents fonc­tion­nent comme des éditeurs de code basés sur le Web et capables de syn­chro­ni­ser les mo­di­fi­ca­tions entre plusieurs uti­li­sa­teurs. Ils per­met­tent de se livrer à la pro­gram­ma­tion en binôme dans des en­vi­ron­ne­ments partagés et à des code reviews par-dessus l’épaule qui se jouent des fron­tières géo­gra­phiques. Ces outils ont énor­mé­ment gagné en po­pu­la­rité avec la pandémie de co­ro­na­vi­rus.

L’en­vi­ron­ne­ment Replit basé sur le Web, ainsi que l’outil LiveShare intégré à l’éditeur Visual Studio Code de Microsoft, peuvent être utilisés en tant qu’éditeurs HTML col­la­bo­ra­tifs. Ces deux outils con­nais­sent bien évi­dem­ment d’autres langages et per­met­tent de tra­vail­ler en col­la­bo­ra­tion sur plusieurs fichiers, mais aussi d’exécuter du code.