Pour vendre, réserver ou faire commander — sur le web et sur téléphone.
Chaque appel pour une réservation, une commande ou un suivi est une transaction que le client aurait faite tout seul, à l'heure qui l'arrange, sans déranger personne. Et chaque appel manqué le soir est une vente qui est allée ailleurs — souvent chez une plateforme qui vous la revend ensuite en prenant sa part.
Le web, l'iPhone et Android à partir du même code. Vous ne payez pas trois développements, et surtout vous ne vivez pas avec trois versions qui divergent — c'est ça qui coûte cher sur cinq ans, pas la première facture.
Inscription, connexion, historique, préférences. La relation est directe entre votre entreprise et votre client : personne ne s'intercale, personne ne prélève sa part, et la liste est la vôtre.
Paiement par carte, abonnements, reçus automatiques. L'argent va dans votre compte marchand, pas dans le mien : je branche la passerelle, je ne me place jamais entre vous et vos encaissements.
Une confirmation, un rappel de rendez-vous, une commande prête. Pas de notification pour faire du bruit : chacune correspond à un moment où le client voulait vraiment savoir, sinon il désinstalle et vous l'avez perdu pour de bon.
Développeur certifié Apple et Google Play. Les fiches, les captures, les versions, les refus de révision et les correctifs qu'ils exigent : c'est moi qui m'en occupe. La première soumission d'une application est l'endroit où la plupart des projets s'échouent pendant des semaines.
Icône, écran de démarrage, couleurs, typographie, captures de boutique. Une application qui ressemble à un devoir d'école se fait juger avant d'être ouverte.
Ce n'est pas un mandat de client, et c'est justement pour ça que je le montre ici : c'est là que je pousse une application beaucoup plus loin que ce qu'un commerce demande. 3D temps réel, carte vivante, multijoueur, et la performance tenue sur un téléphone ordinaire — bâti seul, du moteur de rendu jusqu'à la soumission sur les deux boutiques. Si je peux faire tourner ça sur un téléphone, votre application de réservation n'est pas un problème.
Le travail derrière la citation →Personne n'écrit cette section, et c'est exactement pour ça qu'une PME a peur d'un devis de logiciel : ce n'est pas le montant qui inquiète, c'est de ne pas savoir où il s'arrête. Voici où il s'arrête.
Tout ce qui précède a une fin : un périmètre, un prix, une date de livraison. Ceci n'en a pas. C'est compris avec les six forfaits, ça ne se facture pas à part, et ça ne dépend pas de la taille du contrat.
Vous m'appelez. Jour, nuit, fin de semaine. Pas de formulaire, pas de premier niveau qui vous demande d'avoir redémarré, pas de numéro de dossier. Quand quelque chose brûle, vous avez au bout du fil la personne qui a écrit le code — c'est la seule qui peut répondre vite, parce qu'elle sait déjà où regarder.
Comprendre comment un logiciel se fait attaquer change la façon de le concevoir au départ — pas la façon de le rafistoler à la fin. Je fais du test d'intrusion : je cherche les failles de vos systèmes avant que quelqu'un d'autre les trouve, et comme c'est moi qui les ai bâtis, je sais où sont les endroits laids.
Une entreprise frappée prend ses pires décisions dans les six premières heures, parce que personne autour d'elle ne sait quoi faire et que tout le monde parle en même temps. On contient d'abord, on établit ensuite ce qui est réellement touché — c'est presque toujours moins grave que ce que la note d'écran prétend — et on récupère ce qui est récupérable. Vous parlez à votre assureur et aux autorités avec des faits, pas avec de la panique.
Les demandes de rançon se font en cryptomonnaie, et c'est exactement là qu'une entreprise avance à l'aveugle : d'où vient l'adresse, ce qui est traçable, ce que la police peut réellement faire, et surtout ce que payer ne règle pas — parce que payer ne rend pas les données et ne referme pas la porte d'entrée. Je vous explique ce que vous avez devant les yeux. La décision reste la vôtre et celle de votre assureur, mais elle se prend en sachant.
Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une croyance — et c'est le jour du sinistre qu'on découvre laquelle des deux on avait. Celles des systèmes que je livre sont testées en restaurant pour vrai, et vous savez combien de temps ça prend AVANT d'en avoir besoin.
Pour la personne qui va vous demander si vous n'êtes pas en train de vous faire bâtir un site web déguisé en application. Voici exactement ce que c'est.
Une application qui n'est qu'un navigateur déguisé se fait refuser par Apple, et à raison : elle n'a pas accès à l'appareil photo, aux notifications ni au stockage local, et elle ne fonctionne pas hors réseau. Ici, le code de l'interface est partagé ; les capacités de l'appareil sont natives.
Les mots de passe ne sont jamais stockés en clair et je n'en vois aucun. Jeton de session à durée limitée, renouvellement silencieux, déconnexion à distance. Et les rôles dans une table séparée du profil : jamais un champ « admin » sur la fiche que l'utilisateur peut lui-même modifier — c'est l'une des erreurs les plus courantes et des plus chères.
Aucun numéro de carte ne touche votre serveur ni le mien : le formulaire de paiement appartient au fournisseur, votre application ne reçoit qu'un jeton. C'est ce qui vous évite d'avoir à répondre vous-même aux exigences de conformité des cartes de crédit.
L'application garde son état et sa file d'envoi. Un client dans un stationnement souterrain qui remplit une commande ne la perd pas : elle part quand le signal revient. Une application qui exige du réseau pour afficher un écran déjà chargé est une application mal faite.
Une correction ne devrait pas attendre une révision de boutique de trois jours. Ce qui peut être corrigé côté serveur l'est côté serveur ; les boutiques ne sont sollicitées que quand l'application elle-même change. Sinon la moindre faute de frappe devient un événement.
Je publie sous VOTRE compte d'entreprise Apple et Google, pas sous le mien. Une application publiée sous le compte du développeur est une application dont vous ne pouvez plus rien faire le jour où vous changez de développeur — et ça arrive plus souvent qu'on ne l'avoue.
Rien ici n'est une promesse de brochure : c'est la façon dont je bâtis, et vous pouvez me la faire vérifier par quelqu'un.
Pas besoin d'un cahier des charges ni du bon vocabulaire. Une ou deux phrases sur ce qui est lent, manuel ou impossible en ce moment suffisent.
Au téléphone, avec moi — pas avec un vendeur. On cherche ce qu'il faut vraiment bâtir, et surtout ce qu'il ne faut pas bâtir.
Un montant, et la liste de ce qui est livré pour ce montant. Il ne bouge plus ensuite. Rien à payer tant que vous n'avez pas dit oui à cette liste.
Pas une maquette à commenter : du logiciel que vous ouvrez et que vos gens utilisent pour vrai, le plus tôt possible.
C'est en s'en servant qu'on voit ce qui accroche. Ce qui accroche se corrige avant qu'on bâtisse la suite par-dessus.
Web, App Store, Google Play, votre serveur — selon le projet, et c'est moi qui le fais. Le code vous appartient, et c'est encore moi qui réponds quand vous appelez ensuite.
Dites-moi laquelle. Je vous dis ce que je bâtirais, combien de temps ça prend et ce que ça coûte — sans engagement, et sans jargon.