Vous n'en avez peut-être pas besoin
Le développement sur mesure coûte cher et n'est pas un besoin pour toutes les entreprises. Si votre site affiche de l'information, recueille des formulaires et porte un blog, un système de gestion de contenu tout fait fera l'affaire. Le dire ne sert pas notre chiffre d'affaires, mais corriger un mauvais investissement plus tard coûte davantage.
La ligne de partage est celle-ci : y a-t-il des règles sur le site, ou seulement du contenu ? S'il n'existe pas de prix, de droit ou de calcul qui change d'un utilisateur à l'autre, vous pouvez vous arrêter ici.
En quoi est-ce différent du design ?
Sur un site vitrine, changer une page revient à changer le texte. Ici, changer une seule règle touche tous les écrans, tous les droits et tous les rapports qui en dépendent.
C'est pourquoi la moitié du travail n'est pas du code mais la mise par écrit correcte des règles. C'est aussi la raison pour laquelle nous ne donnons pas de prix avant d'avoir le document de périmètre.
Avec quelle technologie travaillez-vous ?
Nous choisissons selon trois questions : sera-ce encore maintenu longtemps, trouvera-t-on un développeur pour reprendre, et les moteurs de recherche peuvent-ils lire le contenu sans exécuter de JavaScript ?
Ce que nous n'utilisons pas mérite aussi d'être dit : Flash, FrontPage, Fireworks et l'ASP classique n'apparaissent dans aucun de nos projets actuels. Si votre site a été bâti avec cela, le travail qui vous attend n'est pas une mise à jour mais une réécriture.
Quels types de travaux faites-vous ?
- Espaces revendeurs et services : prix selon le rôle, saisie des commandes, suivi des comptes
- Gestion du catalogue produits et des documents techniques, tableaux de variantes et de dimensions
- Circuits de devis : du formulaire au devis PDF, avec suivi des validations et des révisions
- Systèmes de réservation et de rendez-vous, avec capacité et rappels
- Interfaces de gestion interne : demandes, tâches, documents, droits
- Interconnexions : ERP, comptabilité, transport, facturation électronique, terminal de paiement, places de marché
- Reprises : lecture du code, documentation, refonte par étapes
Comment se construit une interconnexion ?
Une interconnexion, c'est deux systèmes qui se parlent sans qu'on saisisse deux fois les mêmes données. C'est là que les projets bloquent le plus souvent : la documentation d'en face est incomplète, les noms de champs ne correspondent pas, et nulle part il n'est écrit ce qui se passe en cas d'erreur.
Nous découpons donc le travail en trois. Un tableau de correspondance des champs : quel champ correspond à quoi. Les cas d'erreur : que se passe-t-il si la connexion tombe ou si les données sont rejetées. Et la logique de nouvelle tentative. Tant que ces trois éléments ne sont pas écrits, nous ne commençons pas le code.
- ERP et comptabilité : transfert des produits, du stock, des comptes et des prix
- Facturation et archivage électroniques : émission des documents via un opérateur
- Transport : création de l'expédition, code-barres, rapprochement du numéro de suivi
- Paiement : terminal bancaire ou prestataire de paiement ; les données de carte ne nous parviennent jamais
- Places de marché : synchronisation des produits et du stock, récupération des commandes
Que faites-vous côté sécurité ?
La sécurité n'est pas un module à part, c'est une habitude tenue à chaque étape. Voici nos règles minimales :
- Tout ce qui vient du navigateur est revalidé sur le serveur ; le contrôle côté client n'est qu'un confort pour l'utilisateur
- Les mots de passe sont hachés avec bcrypt et ne sont stockés en clair nulle part
- Les droits sont vérifiés sur le serveur ; un bouton masqué n'est pas une limite de droits
- Limitation de débit, pot de miel et vérification anti-robot sur les points d'entrée et les formulaires
- Requêtes paramétrées, contrôle du type et de la taille lors des envois de fichiers
- Les données de carte ne descendent jamais sur notre serveur, elles restent dans le cadre du prestataire de paiement
- Inventaire des données, durées de conservation et procédure de suppression, comme l'exige la KVKK, la loi turque sur les données personnelles
- Une fois les sauvegardes en place, la restauration est réellement essayée ; une sauvegarde non testée n'en est pas une
À qui appartiendra le logiciel ?
Le système tourne à votre nom : le domaine est le vôtre, l'accès à l'interface est chez vous, les données qu'il contient sont les vôtres. Vous pouvez exporter vos fiches produits, clients et commandes quand vous le souhaitez. Vous ne nous payez pas de licence annuelle pour que le site reste allumé.
Le transfert du code source est une discussion à part. Le vrai coût d'un logiciel n'est pas de le faire tourner, c'est de le concevoir, de l'écrire et de le documenter ; c'est pourquoi le transfert de code n'entre pas dans le prix du forfait. Les clients qui le souhaitent en parlent lors de l'échange, et nous inscrivons le montant et le périmètre au contrat. Nous le disons d'emblée pour qu'il n'y ait pas de surprise ensuite.
Une fois le transfert de code convenu, le dossier de livraison contient le dépôt Git, une sauvegarde de la base et les fichiers de schéma, la liste des variables d'environnement, les comptes des services tiers, un guide d'installation et la liste des manques connus. Ce dernier point, nous l'écrivons délibérément. Aucun logiciel n'est livré sans manque ; l'honnête est celui qui met les manques sur le papier.
