On nous demande souvent dans quel secteur nous nous spécialisons. Ma réponse est toujours : "Dans aucun." Cela suscite parfois du scepticisme. Pourtant, nous pensons qu'il est utile et juste d'intervenir sur des projets IT dans des secteurs variés. Pourquoi ?
Cycle de vie du développement logiciel
À une époque de digitalisation croissante, oui, je reste volontairement large, la situation se ressemble souvent dans les entreprises : il existe un processus qui est essentiel à l'activité quotidienne. Parfois ce processus est manuel ou repose encore sur des transferts de données papier, parfois il existe déjà une solution logicielle partielle qui a encore besoin d'améliorations ou à laquelle il manque des fonctionnalités. L'approche pour mettre à jour ou remplacer une telle solution est presque toujours identique :
- Analyse des exigences du processus central avec les parties prenantes et les utilisateurs finaux
- Analyse des groupes d'utilisateurs avec les parties prenantes et les utilisateurs finaux
- Planification du périmètre initial (MVP)
- Implémentation itérative
- Validation et tests
Le Software Development Lifecycle (SDLC) n'a rien de nouveau et constitue une pratique standard dans les projets logiciels depuis des années. Cela montre bien que nous réfléchissons d'abord aux exigences, puis, ensuite, idéalement de manière itérative, à l'implémentation de la solution.
Connaissance métier et spécialisation
Comme évoqué plus haut, nous croyons fermement qu'il est important et juste que nous ne soyons pas experts du secteur de nos clients. Cette impartialité aide à analyser les exigences. Pendant l'analyse, les parties prenantes et les utilisateurs décrivent généralement ce qu'ils connaissent et la manière dont ils travaillent aujourd'hui. Or l'objectif est, comme décrit ci-dessus, d'identifier le processus central. Qu'est-ce que cela signifie en pratique ?
- Distinguer les processus centraux des cas limites : à quelle fréquence un scénario donné se produit-il réellement ?
- Décomposer les processus centraux en sous-processus : quels sous-processus doivent être considérés séparément ou même réutilisés ? Quelqu'un a dit Domain-Driven Design ?
- Distinguer les groupes d'utilisateurs de la réalité du terrain : qu'est-ce qui différencie le "vendeur automobile" du "spécialiste SUV" dans son workflow ?
- Identifier les sources de données : quelles données sont essentielles au processus central ?
- Identifier l'interface utilisateur adaptée : desktop, mobile, chat agent ?
Exigences de qualité
Nous savons maintenant comment nous dérivons et implémentons ensemble les exigences fonctionnelles. Mais cela ne garantit pas à lui seul un bon logiciel. La norme ISO/IEC 25010 traite du modèle de qualité des produits logiciels. L'implémentation correcte des exigences fonctionnelles n'en est qu'un aspect. Nous considérons qu'il est de notre responsabilité de poser les bonnes questions pendant l'analyse des exigences, en couvrant aussi d'autres dimensions du modèle comme l'efficience, la sécurité et la fiabilité, pour n'en citer que quelques-unes.
Dans le développement logiciel, on parle ici d'exigences de qualité. Les prendre en compte tôt rend les projets logiciels plus durables et plus réussis. Les ignorer, en revanche, augmente les coûts et les risques.
IA
Alors, qu'est-ce qui change avec des technologies modernes comme l'IA générative, les grands modèles de langage et les agents qui prennent en charge une partie de nos processus métier ?
Absolument rien.
Les applications qui intègrent de l'IA sont avant tout des applications distribuées composées de plusieurs composants, chacun ayant besoin d'une configuration et d'une exploitation séparées tout en communiquant via des interfaces. Nous connaissons cela depuis l'essor des architectures microservices et serverless. Mais le monde d'aujourd'hui est bien plus avancé en matière d'exploitation et de monitoring de telles solutions. De plus, les nombreux retours d'expérience issus de ces applications nous aident à poser les bonnes questions pendant l'analyse des exigences, ce qui boucle d'ailleurs la boucle.
Alors, tous les projets se ressemblent-ils ?
Non. Chaque projet diffère fortement du précédent et du suivant sur le fond. Les parties prenantes et les utilisateurs finaux apportent leur expertise métier au projet. Notre expertise, à nous, consiste à comprendre, dériver et prioriser les exigences avec nos partenaires projet. Notre orientation technique vers des outils éprouvés mais aussi modernes, comme Microsoft .NET, React et TypeScript, nous permet une implémentation rapide et donne à nos partenaires des possibilités de validation très tôt.
Besoin d'aide ?
Vous voulez lancer un projet logiciel mais vous ne savez pas comment structurer l'analyse des exigences et prendre correctement en compte les exigences de qualité ? Nous pouvons vous aider. Contactez-nous via notre page de contact et nous travaillerons ensemble au lancement réussi de votre projet.
