Un gérant décrit son besoin en une phrase : « je veux une application comme celle de mon fournisseur ». Trois questions plus tard, on découvre que ce qui lui coûte réellement du temps, c'est de recopier chaque soir les bons de livraison dans un tableur, et de ne jamais savoir ce qui reste en stock avant d'aller vérifier au dépôt. L'application qu'il décrivait n'aurait rien réglé. Celle dont il a besoin n'existait pas dans sa phrase.

Le problème avant la solution

Un client formule presque toujours une solution, rarement un problème. C'est normal : il a déjà réfléchi, et il présente le résultat de sa réflexion.

Le travail consiste à revenir en arrière. Que se passe-t-il aujourd'hui, concrètement ? Qui fait quoi, à quel moment, avec quel outil ? Où l'information est-elle saisie deux fois ? Qu'est-ce qui produit des erreurs ? Qu'est-ce qui empêche de répondre à un client immédiatement ?

De ces réponses sort une compréhension du besoin réel, qui ne ressemble pas toujours à la demande initiale. Un développeur qui commence par choisir un cadre technique avant d'avoir fait ce travail construit correctement la mauvaise chose.

Transformer une idée en périmètre testable

Un périmètre utile n'est pas une liste d'envies : c'est une série d'énoncés qu'on peut vérifier à la fin.

« Gérer le stock » n'est pas testable. « Enregistrer une entrée de marchandise avec sa quantité et son fournisseur », « afficher le stock disponible par article », « alerter quand un article passe sous un seuil défini » le sont. Chacun de ces énoncés peut être montré, accepté ou refusé.

Le périmètre précise aussi les utilisateurs et leurs droits, les données, les intégrations, ce que le client fournit, les délais, les livrables — et ce qui est explicitement exclu. Un projet dérape rarement sur ce qui était écrit ; il dérape sur ce que chacun croyait évident.

Livrer par étapes plutôt qu'à la fin

Un projet dont le client ne voit rien avant la fin se termine rarement bien. Non par mauvaise foi, mais parce qu'une application se comprend en l'utilisant, et que personne ne sait décrire à l'avance ce qu'il n'a jamais manipulé.

Livrer une version utilisable à intervalles réguliers change la nature du projet : le client corrige le tir tôt, quand une erreur de conception coûte une discussion et non trois semaines de reprise. Cela suppose de découper le travail par valeur d'usage — une fonction complète et utilisable — plutôt que par couche technique.

Les durées annoncées relèvent de l'organisation du prestataire et de la complexité du projet ; elles ne se déduisent d'aucune norme et varient trop pour qu'un chiffre général ait un sens.

Les données sont le squelette

Ce qu'on voit d'une application, ce sont des écrans. Ce qui la fait durer, c'est la manière dont les données sont organisées.

Décider ce qui constitue un article, un client, une commande, une ligne de commande, et comment ces objets se relient, est une décision structurante qu'on ne corrige pas facilement. Une mauvaise modélisation ne se voit pas au début : elle apparaît le jour où l'on veut ajouter une fonction que la structure interdit.

C'est aussi là que se décident des choses très concrètes : quelles informations sont obligatoires, lesquelles peuvent rester vides, ce qui doit être unique, ce qui se supprime réellement et ce qui se marque inactif. Une donnée effacée par erreur dans une application mal conçue ne se retrouve pas.

Choisir des outils qu'un autre pourra reprendre

Le choix technique est souvent présenté comme une affaire de préférence. Il devrait être une affaire de durée de vie.

La bonne question n'est pas « quel est l'outil le plus moderne », mais « qui pourra reprendre ce projet dans trois ans ». Cela oriente vers des technologies largement utilisées, documentées, avec une communauté et des développeurs disponibles localement — plutôt que vers un choix exotique dont le client deviendrait prisonnier.

Les outils no-code ou low-code entrent dans le même raisonnement : ils font gagner un temps réel sur certains besoins et se paient ailleurs — limites fonctionnelles, coût d'abonnement, dépendance à une plateforme, export incertain. Ni supérieurs ni inférieurs par principe : ils conviennent, ou non, à un besoin et à un horizon donnés.

Tester : ce qui doit continuer de marcher

Un test n'a pas pour but de prouver que le code fonctionne le jour de la livraison. Il a pour but de garantir qu'une modification future ne cassera pas ce qui marchait.

Les fonctions critiques — celles dont une défaillance coûte de l'argent ou de la confiance — méritent des tests automatiques : calcul d'un total, enregistrement d'une commande, authentification, permissions. Le reste se teste manuellement selon un scénario écrit.

S'y ajoute la recette avec le client, qui ne teste pas la même chose : lui vérifie que l'application fait ce qui était convenu, dans ses conditions réelles, avec ses données réelles.

Sécurité applicative dès l'écriture

Une application accessible depuis Internet est exposée en permanence, et l'essentiel des attaques courantes est automatisé.

La référence défensive la plus répandue est le Top 10 de l'OWASP, publié par la fondation du même nom : un document de sensibilisation destiné aux développeurs et aux équipes de sécurité applicative, qui recense les catégories de risques les plus critiques pour les applications web et se présente comme une première étape vers un développement plus sûr.

Concrètement, cela se traduit par des réflexes d'écriture : ne jamais faire confiance à une donnée entrante, contrôler les autorisations à chaque action et pas seulement à l'affichage, ne pas inscrire de secret dans le code source, maintenir à jour les bibliothèques utilisées, journaliser ce qui doit l'être, et prévoir des sauvegardes de la base. Un développeur qui livre sans dire comment l'application sera mise à jour laisse une dette qui grandit seule.

Interfaces, accessibilité et preuve

Une interface se juge à l'usage : ce que l'utilisateur voit d'abord, ce qu'il comprend sans explication, combien d'actions lui coûtent une tâche courante, et ce qui se passe quand il se trompe. Un message d'erreur qui dit quoi faire vaut mieux qu'un code technique.

L'accessibilité relève du même travail. Les Règles pour l'accessibilité des contenus Web, publiées par le World Wide Web Consortium à travers son initiative sur l'accessibilité, ont le statut de recommandation du W3C. Elles s'organisent autour de quatre principes — perceptible, utilisable, compréhensible, robuste — et définissent trois niveaux de conformité, A, AA et AAA. Elles ne sont pas contraignantes par elles-mêmes : elles le deviennent lorsqu'une législation nationale les reprend, ce que certains pays font et d'autres non.

Lorsqu'une application recueille un engagement — validation d'une commande, acceptation de conditions, signature d'un document —, la question de la preuve se pose. La Loi type de la CNUDCI sur les signatures électroniques, adoptée le 5 juillet 2001, propose aux États un cadre fondé sur l'équivalence fonctionnelle, qui permet à une signature électronique de satisfaire une exigence légale de signature lorsqu'elle offre les garanties requises, et sur la neutralité technologique. Une loi type n'est pas un traité : elle ne vaut que là où un État l'a transposée, et les exigences concrètes se lisent dans le droit national. Côté développeur, ce qui relève de son métier est de conserver des traces datées, cohérentes et non modifiables après coup.

Reprendre le code de quelqu'un d'autre

Une part importante du travail consiste à reprendre un projet laissé en plan. C'est une mission différente d'un développement neuf, et elle commence par un audit honnête.

Cet audit répond à trois questions : qu'est-ce qui fonctionne réellement, qu'est-ce qui est récupérable, et qu'est-ce qui coûtera plus cher à réparer qu'à réécrire. La réponse déplaît parfois. La donner quand même est ce qui distingue un professionnel de quelqu'un qui prend le projet et découvre le problème une fois payé.

L'audit examine aussi ce qui n'est pas du code : les accès existent-ils, la base est-elle sauvegardée, le nom de domaine et l'hébergement sont-ils au nom du client, y a-t-il une documentation, et le prestataire précédent a-t-il tout remis.

Livraison, accès, documentation

Livrer, ce n'est pas mettre en ligne. C'est transmettre de quoi continuer sans soi.

Cela comprend le code source et son historique, les accès aux environnements, les comptes techniques et leurs droits, la procédure de déploiement, l'état des sauvegardes et la façon de les restaurer, une documentation courte, et une formation aux fonctions d'administration.

Les identifiants se transmettent avec méthode : comptes nominatifs plutôt que compte partagé, droits limités au nécessaire, authentification renforcée là où elle existe, révocation des accès du prestataire à la fin de la mission. Un mot de passe envoyé dans une conversation de groupe ou stocké dans un fichier non protégé ne se reprend pas.

Quand l'intelligence artificielle écrit du code

L'assistance par IA fait partie du quotidien de beaucoup de développeurs, et elle fait gagner du temps réel sur ce qui est répétitif : squelettes de fonctions, tests, conversions, documentation, explication d'un code inconnu.

Elle appelle une discipline précise, parce que « ça fonctionne » n'est pas un critère suffisant. Un code peut produire le bon résultat tout en étant fragile, inefficace, non sécurisé ou impossible à maintenir. Le code généré se relit, se comprend, se teste et s'intègre comme n'importe quel autre — la responsabilité de ce qui est livré reste entière.

Deux précautions s'ajoutent. La confidentialité d'abord : du code client, des données réelles ou des identifiants ne se collent pas dans un outil sans savoir ce qu'il en fait. Les droits ensuite : ce qui est produit peut s'inspirer de sources dont la licence importe, et un professionnel s'assure de ce qu'il a le droit de livrer.

Dans le contexte africain

Les conditions d'exercice varient fortement d'un pays et d'une ville à l'autre, et il n'existe pas de contexte africain unique. Plusieurs contraintes reviennent néanmoins dans certains contextes et méritent d'être conçues, pas subies.

Lorsque la connexion est irrégulière ou facturée au volume, une application qui exige une connexion permanente devient inutilisable la moitié du temps. Concevoir un fonctionnement dégradé — saisie hors ligne, synchronisation différée, allègement des échanges — n'est alors pas une option de confort. Lorsque le téléphone est le poste de travail principal, l'interface se conçoit d'abord pour le petit écran. Lorsque le paiement mobile est le moyen courant, son intégration conditionne l'usage réel de l'application, et les solutions disponibles diffèrent d'un pays à l'autre.

Sur le plan des données, le cadre applicable dépend du pays. Le Cadre de politique des données de l'Union africaine, publié le 28 juillet 2022, vise à renforcer et harmoniser la gouvernance des données sur le continent afin de créer un espace de données partagé au service d'une économie numérique inclusive. Il s'agit d'une orientation, non d'une législation contraignante : ce qui s'impose réellement à une application donnée découle du droit national, et notamment des règles éventuelles sur la localisation ou le transfert des données.

Enfin, la disponibilité de développeurs varie beaucoup selon les villes. C'est un argument supplémentaire pour choisir des technologies répandues : un client ne devrait jamais dépendre d'une seule personne pour faire évoluer son outil de travail.

Ce qu'un développeur ne promet pas

Un développeur ne garantit pas l'absence de défaut, ni qu'une application n'aura jamais besoin d'évoluer, ni qu'un service tiers restera disponible et gratuit, ni qu'un délai sera tenu quelles que soient les circonstances. Il dépend d'hébergeurs, d'interfaces de programmation, de bibliothèques et d'opérateurs : il ne peut pas s'engager sur une disponibilité totale d'une chaîne qu'il ne maîtrise pas.

Ce qu'il engage se vérifie : un besoin compris et reformulé, un périmètre testable, des livraisons régulières, des tests sur les fonctions critiques, un code documenté et remis, des accès transmis, une base sauvegardée et une application que le client peut faire reprendre par quelqu'un d'autre.

C'est aussi ce qui rend son activité crédible : un nom professionnel, des coordonnées stables, des réalisations présentées telles qu'elles sont, un devis qui détaille chaque fonctionnalité, un contrat qui dit à qui appartient le code, des factures, et un suivi des demandes après la livraison.

Enfin, cet article décrit un métier ; il ne remplace ni un cahier des charges ni un avis juridique. Les règles évoquées varient d'un pays à l'autre.