Développement Logiciel on CTOMultiplier

Comment adopter l'IA dans une équipe logicielle

Sun, 16 Nov 2025 13:15:38 +0000

Votre stratégie d’adoption de l’IA consiste-t-elle à distribuer des licences Copilot, Cursor ou Claude et à les laisser se débrouiller pour apprendre à les utiliser ?

Au cours de l’année écoulée, j’ai constaté que c’était une stratégie répandue dans les entreprises de logiciels, dont les équipes font face à une charge de travail élevée et qui, par manque de connaissances et de temps, voient l’IA comme une technologie de plus que chaque développeur peut apprendre en autodidacte.

Guide pour un développement robuste avec l'IA : Cursor et Github Copilot

Wed, 14 May 2025 15:48:12 +0000

Les assistants de code IA se sont récemment répandus grâce à la puissance qu’ils offrent pour accélérer le développement logiciel. Cependant, apprendre à les utiliser n’est pas aussi simple qu’écrire un simple prompt. La courbe d’apprentissage pour exploiter pleinement ce qu’ils offrent n’est pas aussi faible qu’on pourrait le penser. Si nous la sous-estimons, nous risquons a) de produire du code de mauvaise qualité avec des erreurs et des failles de sécurité ou b) de faire un usage limité des capacités et d’obtenir moins de bénéfices que ceux disponibles.

IA dans le developpement logiciel : Hype ou Game Changer ?

Thu, 13 Mar 2025 10:59:03 +0000

Nous sommes en 2028, 6 ans se sont ecoules depuis le boom de l’IA generative avec l’apparition de ChatGPT et de ce qui fut une vague d’adoption de l’IA generative pour developper des logiciels. Cependant, apres le hype qui s’est produit en 2023 et 2024, l’utilisation des copilots et assistants de code bases sur l’IA a progressivement diminue. On a observe qu’au fond ils n’offraient pas beaucoup de valeur, car la majorite du code qu’ils produisaient etait incorrect et de qualite mediocre, et que les developpeurs passaient plus de temps a corriger les erreurs introduites par l’IA qu’ils n’en economisaient. Cela a provoque un affaiblissement progressif des initiatives d’adoption jusqu’a leur disparition du debat technologique, rappelant le destin ephemere du metaverse.

Savez-vous ce qu'est le DPE ?

Wed, 27 Sep 2023 07:23:39 +0000

DPE signifie Developer Productivity Engineering et c’est le nom d’une nouvelle discipline qui vise à améliorer la productivité des développeurs à travers l’automatisation, l’observabilité et l’amélioration des outils.

Le travail d’un développeur lorsqu’il programme comporte trois phases : code -> build -> test. Le développeur répète cette séquence des dizaines voire des centaines de fois par jour. Et dans de nombreux cas, les phases de build et de test peuvent prendre de l’ordre de plusieurs minutes. Par exemple : si le build d’une application prend 5 minutes et que le développeur effectue 10 builds par jour, cela fait 50 minutes d’attente par jour pour le développeur. De même, la phase de test peut augmenter le temps d’attente du développeur. Multipliez cela par le nombre de développeurs dans une entreprise et le coût est significatif.

Guide pour faire des revues de code dans votre équipe

Tue, 25 Jul 2023 15:42:32 +0000

Les revues de code sont une pratique qui s’est généralisée ces dernières années, où un ou plusieurs développeurs examinent le nouveau code implémenté par un autre collègue, dans le but de détecter des problèmes de qualité du code, des bugs, des vulnérabilités, de mauvaises pratiques, etc. Cela permet de raccourcir les boucles de rétroaction, ce qui est très bénéfique car plus un problème est découvert tard, plus le coût de sa correction est élevé et plus l’impact potentiel sur l’activité est important.

Quand les abstractions fuient

Thu, 15 Jun 2023 18:47:25 +0000

Dans le monde du logiciel, nous utilisons constamment des abstractions pour faciliter notre travail, car elles nous abstraient d’autres domaines et réduisent considérablement la complexité à laquelle nous devons faire face. Un exemple d’abstraction est les ORM. Un ORM nous permet d’abstraire l’application de la base de données utilisée. Au lieu de devoir écrire des requêtes (spécifiques au moteur de base de données) pour accéder aux données, l’ORM nous permet d’utiliser le langage de programmation que nous utilisons pour coder l’application, également pour accéder aux données. Quiconque a utilisé des ORM sait que dans de nombreux cas, l’abstraction fonctionne bien et apporte beaucoup de valeur, mais lorsque l’application nous oblige à récupérer plusieurs entités liées, entre autres exemples, c’est là que nous commençons à voir les limitations. Dans ces cas, il est courant que les ORM ne génèrent pas toujours les requêtes optimales, ou qu’ils nous obligent à écrire un code excessivement complexe, si bien que parfois nous finissons par écrire des requêtes directement dans le langage de la base de données sous-jacente. Cela signifie mettre de côté l’abstraction pour ces cas.