Accélérer l'innovation : automatiser le développement logiciel pour un avantage concurrentiel

Le développement logiciel traditionnel est lent. Il est temps de repenser.

Il y a près de trois ans, Satya Nadella de Microsoft a déclaré que « chaque entreprise sera une entreprise logicielle ». Aujourd'hui, le marché mondial du logiciel de 500 milliards de dollars est en passe de doubler pour atteindre 1 000 milliards d'ici 2030.

J.P. Morgan compte 40 000 ingénieurs logiciels (plus qu'Alphabet) selon son dernier dépôt. Chaque grande entreprise court pour embaucher des ingénieurs afin de dépasser la concurrence. Le gros problème est que le développement logiciel traditionnel est lent, fragmenté et gaspilleur.

Par exemple, chaque semaine, l'ingénieur logiciel moyen passe 4 heures à attendre que les tests se terminent, 3,5 heures à attendre les builds, et 3 heures à gérer les environnements — plus d'un quart de sa semaine de travail sans rien créer de valeur. Quand on considère que les ingénieurs sont souvent les personnes les mieux payées des organisations, c'est clairement un gros problème. Cependant, les choses changent.

L'une des principales plateformes de développement, CircleCI, a parié que l'IA et l'automatisation seraient la clé pour accélérer l'innovation logicielle et libérer les ingénieurs pour qu'ils fassent un travail important. Au cours de la dernière année, l'entreprise a introduit plusieurs améliorations d'automatisation et d'apprentissage automatique qui ont réduit de 50 % le temps d'attente des ingénieurs. C'est l'une des nombreuses raisons pour lesquelles plus de 300 000 développeurs, y compris ceux de Facebook, Spotify, GoPro, InstaCart et bien d'autres, se sont tournés vers CircleCI pour aller plus vite.

L'entreprise est dirigée par Jim Rose — un fondateur à six reprises avec des investissements passés de Google Ventures, Foundation Capital et Marc Andreessen. Depuis qu'il a rejoint CircleCI il y a un peu plus de quatre ans, Rose a augmenté le chiffre d'affaires de plus de 450 % et fait de l'entreprise une entité vraiment passionnante.

Intéressé par l'automatisation du développement logiciel et l'accélération de l'innovation, Information Age a interrogé Rose sur le sujet.

Quel est l'état actuel du marché du logiciel ?

Actuellement, il y a encore beaucoup d'entreprises et d'individus qui effectuent différents processus manuellement. Quand on pense au processus de transformation numérique, il s'agit vraiment d'essayer de favoriser une équipe de développement logiciel.

Premièrement, on essaie de sortir le logiciel des centres de données sur site pour le placer dans des environnements cloud-native, où l'on peut accéder à la capacité de calcul instantanément.

Deuxièmement, le logiciel, traditionnellement ou dans de nombreux cas, a été vu comme une directive ou un complément à l'activité principale. Maintenant, vous avez toutes sortes d'entreprises, des banques aux constructeurs automobiles en passant par les détaillants, qui réalisent que le logiciel est au cœur de ce qu'elles font. Et elles doivent donc déterminer ce qu'elles possèdent et consolider leurs actifs et les intégrer comme un standard.

Une fois que les entreprises ont cet accès instantané au calcul et qu'elles ont des structures en place dans lesquelles les développeurs peuvent travailler, ce qui se trouve entre les deux aujourd'hui est généralement un mélange disparate de différentes plateformes et processus.

Dans la plupart des cas, vous avez des processus de publication logicielle en cascade très longs qui comportent beaucoup d'étapes manuelles et beaucoup de scripts manuels. Dans certains cas pour des ateliers plus avancés, ils peuvent avoir la première génération de solutions d'automatisation en place, mais à mesure que les équipes accélèrent, celles-ci commencent à se casser.

Et c'est là que nous intervenons pour aider les entreprises à naviguer. Alors que leurs équipes logicielles accélèrent, elles construisent plus de logiciels et essaient de le faire plus vite ; afin d'être à la fois réactives aux opportunités du marché mais aussi aux changements négatifs potentiels. Les entreprises doivent complètement repenser la façon dont tous ces éléments sont assemblés.

Cette vitesse dont vous parlez est-elle le principal obstacle dans le développement logiciel ?

Les entreprises et les équipes de développement essaient d'accélérer car le marché accélère. Elles essaient de comprendre comment travailler rapidement pour pouvoir saisir les opportunités.

La seule façon d'y parvenir est d'automatiser réellement toutes les étapes qui n'ont pas nécessairement besoin d'intervention humaine, car au lieu de le faire en minutes, heures et jours, vous pouvez le faire en secondes.

Alors que les équipes accélèrent, et que le logiciel est votre vitrine principale vers votre client, vous devez vous assurer que les niveaux de qualité sont élevés ; vous devez vous assurer qu'il ne plante pas ou que vous n'avez pas de vulnérabilités de sécurité, par exemple.

Donc, quand on pense à l'agile, il s'agit d'essayer de devenir plus agile, tant du point de vue de la qualité que de la vitesse.

Aux États-Unis, tout est question de vitesse, mais en allant plus vite, en intégrant de plus petits morceaux et en étant capable de publier du logiciel de manière plus cohérente, votre logiciel devient intrinsèquement meilleur. Toutes ces peurs autour du déploiement disparaissent quand vous le faites cinq, huit, 15 fois par semaine, et dans certains cas, nous avons des clients qui le font 100 fois par jour.

Le déploiement devient un non-problème.

Du côté de la qualité, l'un des gros problèmes du développement logiciel dans le passé est que si vous ne publiez qu'une fois par trimestre, vous avez beaucoup de mal à vous assurer que tous les changements que vous introduisez dans votre application fonctionnent réellement ensemble. Souvent, vous voyez des entreprises faire une grosse publication « big bang » et ensuite, après, elles passent les 60 à 90 jours suivants à essayer de corriger toutes les choses qui ont régressé et cassé. Avec cette méthode, votre cycle logiciel ralentit, mais la qualité de l'application elle-même en pâtit aussi.

Du point de vue agile, c'est ce que les gens essaient d'adresser.

Comment une organisation peut-elle changer pour accueillir, soutenir et favoriser les équipes de développement logiciel ?

Il y a plusieurs façons.

Premièrement, les développeurs sont difficiles à embaucher, donc vous voulez vous assurer que tout le temps passé du point de vue du développement est dédié à la construction de votre logiciel spécifique, quel qu'il soit ; si vous êtes une banque, construire une excellente application bancaire, si vous êtes une application e-commerce, construire une excellente application e-commerce. Je pense que l'un des grands domaines dans lesquels les gens ont sous-investi est que les développeurs logiciels ont historiquement construit des choses. C'est ce qu'ils font, ils construisent du logiciel. Donc le cycle de développement a été sous-investi du point de vue des applications tierces.

Il y a juste des choses comme, par exemple, l'automatisation des tests et l'infrastructure de livraison continue que les équipes n'auraient pas à construire elles-mêmes. Vous feriez beaucoup mieux de l'acquérir auprès de quelqu'un d'autre qui se spécialise dans ce domaine pour pouvoir vous concentrer sur ce dans quoi vous êtes bon. Ce serait comme dire à quelqu'un qu'il doit construire une cafetière et lui donner un tas de tubes en cuivre, de la soudure et des vannes. Vous ne feriez jamais cela. Mais historiquement, le développement a été traité de cette façon. Donc mettre définitivement les bons outils et plateformes en place est vraiment critique, tout au long de la pile, du centre de données jusqu'aux outils de planification.

Je pense que la deuxième partie est que dans un modèle en cascade traditionnel, le développement logiciel joue généralement le rôle de receveur, donc l'application est définie beaucoup plus tôt dans le processus et puis, au moment où l'équipe de développement la reçoit, un certain nombre de décisions ont été prises qui peuvent ou non fonctionner réellement et peuvent ou non être réalisables ou faciles à faire.

Il y a cette notion de « shift left », qui consiste à pousser le développement de plus en plus haut dans le cycle de planification pour que les préoccupations ou les besoins de l'équipe de développement soient pris en compte à la fois dans la construction de l'application et dans sa livraison. Et puis, quand on y pense d'un point de vue opérationnel, cela signifie qu'il faut vraiment réfléchir à la façon dont une application est exploitée beaucoup plus tôt dans le cycle de vie. Par exemple, si vous essayez de construire des applications cloud-native, vous devez les architecturer d'une manière très particulière, ce qui signifie que vous devez prendre cette décision et faire partie de ce processus beaucoup plus tôt.

Quand les équipes adoptent des processus plus « software-first » et agiles, vous vous retrouvez avec une triangulation des préoccupations. Vous avez les gens, les propriétaires d'entreprise et les chefs de produit qui possèdent le « pourquoi » vous construisez quelque chose. Vous avez les architectes techniques et les développeurs logiciels qui parlent vraiment du « comment » vous le construisez. Et puis vous avez les opérateurs, ceux qui sont responsables de l'exécution, qui déterminent ce que vous exécutez réellement à la fin de tout ce processus. Donc tout le monde doit être impliqué. Et cela peut être une transition difficile pour certaines entreprises.

Comment l'IA et l'automatisation peuvent-elles stimuler et améliorer l'innovation logicielle ?

Avec l'automatisation, vous pouvez automatiser des tâches à la fois prédéterminées et auto-apprenantes. Un exemple pourrait être si chaque fois que vous essayez de publier un logiciel, vous devez faire un test tiers contre un autre système de paiement tiers. Dans le passé, pour ces tâches, vous auriez dû engager une équipe QA qui essaierait essentiellement de traiter des transactions et de le faire manuellement, ce qui est incroyablement lent. C'est aussi incroyablement sujet aux erreurs et aux complications.

Ce sont des exemples parfaits de tâches qui devraient être entièrement automatisées dans votre suite de tests — toutes ces choses que vous savez que vous allez faire encore et encore, vous devriez automatiser ces tâches pour les rendre déterministes et prévisibles. Et finalement rapides.

Il y a des opportunités de prendre ces tâches répétitives que toute minute passée par un développeur à les refaire encore et encore est une perte de temps et, franchement, une perte d'argent.

Alors quand vous regardez l'IA et le logiciel qui est en train d'être construit, au lieu de penser à pousser du logiciel déterministe prédictif, ce que vous faites, c'est pousser un modèle. Et le modèle est un bac à sable de notions préconçues de comment quelque chose pourrait fonctionner et puis, au fur et à mesure que les gens le traversent et que les tests sont exécutés, le modèle change et évolue en apprenant davantage sur comment les choses fonctionnent ou ne fonctionnent pas. Cela met une pression incroyable sur le système de test.

Quand on pense à certains des dérapages de l'IA quand vous avez des situations où il y a un biais inconscient intégré dans l'IA, où l'IA devient un peu folle et commence à bloquer les gens hors de certaines applications, ou arrête des choses, ce sont toutes des situations qui, d'un point de vue test, sont difficiles.

Cela devient de plus en plus compliqué, mais c'est aussi devenu beaucoup, beaucoup plus rapide et plus réactif. Donc vous ne verrez que l'inclusion de l'IA et de l'apprentissage automatique dans le développement logiciel continuer à augmenter. Mais maintenant, vous devez avoir tous les cadres nécessaires en place pour pouvoir tester tous ces changements.