5 règles pour mener à bien son projet informatique


Cette année 2016 a été riche en expertises pour Digitam. Bien que les besoins de nos clients furent variés, cet article est condensé en 5 thèmes des leçons qu’ont eu à tirer nos clients pour progresser dans la réalisation de leur projet informatique.

1 – Besoin et marché, deux notions différentes

En d’autres termes, avoir besoin de quelque chose n’implique pas forcément que l’on soit prêt à payer pour l’obtenir. Dans le développement d‘un produit, il est crucial de s’assurer que la solution technique développée est vendable. La sécurité informatique (cybersécurité) bien qu’à la mode, ne génère pas un chiffre d’affaires à la mesure de sa popularité.

Parfois, « c’est un tort d’avoir raison trop tôt », et il est opportun de lancer son offre au moment où le marché est prêt à la recevoir. D’autres fois, le modèle économique ne fonctionne tout simplement pas (abonnement trop cher, cible trop sollicitée par les démarchages…) : ne pas hésiter alors à se faire accompagner, demander conseil. Le lancement d’une campagne de crowdfunding permet également de jauger de la capacité à monétiser un produit. Argument qui pourra faire pencher favorablement la balance lors d’une levée de fond.

2 – Les sirènes du lean startup : la réalité des spécifications techniques

Dans l’univers des électroniciens / informaticiens, écrire de la documentation n’est pas vraiment populaire. Le Lean Startup propose d’ailleurs de « dégraisser » les processus d’une entreprise pour se concentrer sur le client, le produit et la façon de le monétiser. Ceci en utilisant des itérations courtes c’est à dire aboutir rapidement à un produit fonctionnel même partiellement.

À itérations courtes, spécifications courtes, mais spécifications quand même ! Le risque, et nous l’avons constaté chez certains de nos clients est de rater des éléments structurants du produit et de devoir refaire un design de cartes et de code, car un besoin a mal été capturé. Agilité et rigueur peuvent se marier et faire un excellent ménage !

3 – Le développement logiciel un métier

La phrase « ce n’est que du logiciel » prononcée par un client nous a souvent fait réagir, elle est symptomatique d’un manque de connaissance du métier d’informaticien. Non : le logiciel n’est pas une extension de l’électronique, mais une discipline à part nécessitant des compétences et des outils associés. Soufrant de son manque d’existence tangible et concrète le firmware d’un équipement est souvent sous-estimé en termes de complexité, et les RH (quand elles existent) ont du mal à appréhender les compétences requises et les fiches de postes sont souvent inadaptées.

4 – Processeurs généralistes, problématiques spécifiques

Avec l’émergence des processeurs de type SOC, sur un même processeur via des systèmes d’exploitation généralistes (comme FreeRTOS), la tentation est grande d’y concentrer les tâches. Et ainsi limiter le travail de routage, augmenter la généricité de l’architecture. Il faut toutefois faire attention aux excès. Une trop grande concentration des tâches sur un processeur peut impacter ses temps de réponse et sa capacité à assurer des contraintes de type temps réel. D’autre part, séparer les fonctions sur des processeurs différents oblige à rendre son code modulaire, enfin il sera possible dans ce cas de limiter le code qui devra être sujet à certification. On peut imaginer le code critique sur un microcontrôleur, communiquant avec une interface graphique présente sur une carte ARM9.

5 – L’open source : attention aux overdoses

Le noyau Linux, Qt, Gtk+, libUSB … Autant de briques logicielles gratuites utilisées dans les produits connectés qui permettent souvent de diviser le temps de développement par un grand facteur. Ces briques toutes faites, comme tous les développements logiciels sont sujettes aux bugs, et l’activité de test n’est pas le fort du développeur de programmes open sources. Ce qui est d’autant plus vrai que la brique en question est utilisée dans cadre qui sort un peu de ce qui en est fait habituellement (driver exotique, utilisation poussée du « low power » …)

Il convient donc de faire la liste des briques logicielles importées du monde open source, et les passer à un banc de test afin de valider leur robustesse au regard de la spécificité du projet.

Seules ces briques ainsi qualifiées seront habilitées à faire partie du produit, tout changement (y compris un changement de version mineure) devra relancer le processus de qualification.

D’autre part, les licences GPL sont contaminantes … mais cela sort du cadre de cet article. Peut-être en parlerons-nous dans un prochain article !