izilaw, reprise en main et refonte de la plateforme Django de rendez-vous juridiques

Une plateforme Django à remettre au goût du jour

À propos d’izilaw

izilaw est une plateforme française de prise de rendez-vous en ligne avec les professionnels du droit : avocats, notaires et commissaires de justice. Le particulier y compare les fiches, voit le tarif du premier rendez-vous et réserve un créneau ; le professionnel y gère son agenda, synchronisé avec Google Agenda ou Outlook, ses devis, ses significations d’actes et ses factures. Plus de 27 000 pages sont servies par une application Django développée sur mesure depuis 2017 et hébergée sur Heroku, complétée par un guide de fiches pratiques.

Pourquoi nous avoir contactés

Après plusieurs années sans évolution majeure, la plateforme ne pouvait plus être mise à jour : Heroku n’acceptait plus la version de Python sur laquelle elle reposait, et sa version de Django, la 1.11, refusait de démarrer sur une version plus récente. L’équipe d’izilaw cherchait un prestataire capable de reprendre seul ce code dont les développeurs d’origine étaient partis, de le remettre sur des bases actuelles, puis de le faire évoluer : sécurité, conformité, design, contenus. Un projet d’accompagnement technique mené en trois temps, d’août à octobre 2026.

Objectifs et fonctionnalités clés

Retrouver d’abord la capacité de déployer, sans rien casser d’un service utilisé chaque jour. Rendre ensuite les mises à jour sûres et routinières, pour ne plus jamais accumuler neuf ans de retard. Offrir enfin à la plateforme une interface moderne, rapide et accessible, et confier les fiches pratiques à un WordPress que l’équipe peut alimenter sans développeur.

Enjeux et contraintes

Le code ne comptait aucun test automatisé et peu de documentation. Les parcours sont nombreux et sensibles : six profils d’utilisateurs, des paiements, des factures PDF, des agendas synchronisés, des pages de rendez-vous intégrées en marque blanche sur les sites de cabinets partenaires. Chaque modification devait donc être prouvée sans régression avant d’atteindre la production, et la plateforme rester en ligne pendant toute l’intervention.

Les étapes du projet

Montée de version : de Django 1.11 à Django 5.2 LTS

Un filet avant de toucher au code. Faute de tests, nous avons d’abord écrit un outil qui photographie le site page par page (code de réponse, structure du document, texte visible, formulaires, liens, images), sur une copie locale sous Docker avec PostgreSQL 17. Cette photographie, prise sous l’ancienne version, servait de référence à chaque étape.

Deux montées de version indissociables, d’un seul tenant. Python passe de 3.9 à 3.12 et Django de 1.11 à 5.2 LTS, maintenu jusqu’en avril 2028. Quatre versions majeures de Django franchies d’un coup : routes réécrites dans 14 fichiers, 32 clés étrangères explicitées sans changer le schéma, vues d’authentification et stockage des fichiers portés sur les API actuelles. Le déploiement passe sur la pile conteneur de Heroku. Résultat : 44 pages sur 44 identiques à la référence, et une plateforme de nouveau déployable.

Industrialisation : des mises à jour sûres et des tests partout

Des dépendances figées et une mise à jour en une commande. Les 112 composants Python sont verrouillés à la version près. Une seule commande enchaîne mise à jour, reconstruction, contrôles, tests et comparaison des pages avant et après ; Dependabot propose les correctifs de sécurité et une intégration continue GitHub vérifie chaque modification. Cinq composants abandonnés ont été remplacés, dont l’éditeur CKEditor 4 par TinyMCE 7 et l’ancienne connexion à Google Agenda par la bibliothèque officielle actuelle.

De zéro à 1 668 tests automatisés. Ils couvrent les parcours qui comptent (prise de rendez-vous, devis, signification, paiement, factures) et simulent les services extérieurs, si bien qu’aucun test n’envoie de vrai courriel ni n’appelle de vraie API. Des balayages visitent toutes les pages du site sous les six profils, contrôlent chaque lien interne et chaque fichier référencé. C’est ce filet qui a permis d’aller vite ensuite, tout en livrant sereinement : il bloque toute mise en production tant qu’un seul test échoue.

Une plateforme assainie. Les intégrations qui ne servaient plus (anciens partenaires, prestataire de paiement, traceur publicitaire) sont retirées avec leurs tables. Les bibliothèques chargées depuis quatre serveurs tiers sont désormais servies par izilaw.fr. Une revue de sécurité complète a accompagné ces chantiers, avec limitation des tentatives de connexion, en-têtes HTTP de sécurité et authentification du courrier (SPF, DKIM, DMARC). Le domaine passe derrière Cloudflare, une purge automatique des pièces jointes, réglée sur leurs durées de conservation, est en place, et le géocodage Google est mis en cache pour réduire les appels facturés.

Refonte du front-end : de Bootstrap 3 à une charte sur mesure

Le socle d’abord. Bootstrap 3.3.7 et jQuery cèdent la place à Bootstrap 5.3.8 : 82 gabarits Django, près de 1 200 classes de grille et 458 icônes convertis, les icônes passant d’une police à un sprite SVG limité aux pictogrammes utilisés.

Puis une refonte complète. Un design system documenté conserve les couleurs du logo et adopte Atkinson Hyperlegible Next, une police conçue pour la lisibilité. Soixante-dix-sept maquettes, relues sous l’angle de la couverture de l’existant, de l’accessibilité et de la navigation, couvrent les pages publiques, les tunnels de rendez-vous et de devis, les espaces professionnel et client, les pages d’erreur et les courriels. Sur mobile, la fiche d’un professionnel affiche son identité, quatre créneaux et le bouton de réservation dès le premier écran.

Une intégration pensée pour la performance. Les pages refaites se passent de jQuery ; chacune charge une seule feuille de style et une feuille critique en ligne de moins de 7 Ko compressés. Les photographies sont servies en AVIF, Google Maps ne se charge qu’au premier usage du champ d’adresse, et les 53 gabarits de courriels transactionnels adoptent la même charte, en HTML et en texte. Les maquettes ont été comparées au rendu final, côte à côte, à 375 et 1 280 pixels de large.

Association à WordPress : un guide pour les contenus

Chaque outil à sa place. Django reste maître de ce qui relève de l’application (recherche, fiches, rendez-vous, espaces connectés) ; les 143 fiches pratiques rejoignent le Guide, un WordPress sous GeneratePress et GeneratePerf, où l’équipe éditoriale les rédige et les met à jour en autonomie. Les deux sites partagent la même charte et le même en-tête : pour le visiteur, ils ne font qu’un.

Une extension WordPress sur mesure. Elle déclare le type de contenu des fiches, expose l’arborescence du Guide pour que les menus de l’application Django restent synchronisés (avec une copie de secours si le Guide ne répond pas), et programme la péremption : chaque fiche reçoit une date d’actualisation, signalée à l’équipe dans l’administration et par un courriel mensuel. La bascule s’est faite sans perte de référencement : 143 redirections permanentes, 209 liens internes réécrits vers leur adresse finale, chaque étape répétée sur un banc d’essai avant la production.

Compte-rendu d’intervention

Chaque lot a été validé en préproduction avant d’être proposé pour la production, avec sa procédure de retour arrière. Deux comptes rendus détaillent, poste par poste, ce qui a été fait, comment c’est vérifié et ce qui reste à décider, et un journal horodaté trace chaque action. L’équipe d’izilaw dispose ainsi d’une plateforme documentée, qu’elle peut confier demain à n’importe quel développeur Django.

Reprendre une application sur mesure vieillissante

Peut-on moderniser une application Django sans tout réécrire ?

Oui, et c’est souvent le meilleur choix. Le code d’izilaw portait neuf ans de règles métier éprouvées : le réécrire aurait coûté des mois et réintroduit des défauts déjà corrigés. Une montée de version méthodique, adossée à un filet de non-régression, garde ce capital et remet le socle à jour en quelques semaines.

Pourquoi associer WordPress à une application Django ?

Parce que chacun excelle dans son domaine. Django porte la logique applicative, les comptes et les paiements ; WordPress offre aux rédacteurs un éditeur familier, des révisions et un écosystème de référencement éprouvé. Relier les deux par une extension et une API légère évite de redévelopper un CMS dans l’application, et libère les développeurs des demandes de contenu.

Quel prestataire pour reprendre une application Django, Python ou Heroku ?

Un prestataire qui maîtrise la technologie, mais surtout la méthode : mesurer avant d’agir, sécuriser chaque changement par des tests, livrer par lots vérifiés et documenter. C’est ainsi que nous travaillons, quelle que soit la technologie, d’une application Python sur Heroku à une boutique Shopify, un site Drupal ou PrestaShop. Si votre plateforme sur mesure ne suit plus, notre prestation de refonte et notre accompagnement technique sont faits pour elle.

La stack technique

Le résultat en chiffres

Mesures PageSpeed Insights sur mobile, avant et après la mise en production de la refonte ; suite de tests exécutée sur la version en production.

Accueil : score de 94 à 98,5, poids de 1 005 à 199 Ko. Recherche : score de 73 à 98, plus grand affichage de 8,0 à 2,3 s. Connexion : score de 73 à 99,5, décalage de mise en page (CLS) de 0,78 à 0. Sur les pages refaites, les mesures d’accessibilité aux trois largeurs d’écran ne relèvent plus aucun défaut. La plateforme tourne sur Python 3.12 et Django 5.2 LTS, maintenus jusqu’en 2028.

Votre application sur mesure mérite le même traitement ? Découvrez notre accompagnement technique.

La suite et fin en images