Hey

,
J'ai regardé rapidement l'interface, les sources (HTML et PHP) et voici mes premières impressions.
Bon travail, continue

.
Merci HyWaN de tes remarques je vais juste les commenter histoire d'expliquer un peu mes choix de développement :
Niveau maintenance, ça vaut quoi ? Pour un projet qui commence à être important (plusieurs dizaines de fichiers), je me serais plutôt tourné vers de l'objet. Note, c'est un choix.
OpenDCF est un fork de factux entièrement développer sans objet et php4.
Il etait évident que je n'allait pas tout réecrire, et j'ai beaucoup hésiter à ajouter de l'objet ou non.
Je n'ai pas considérer qu'ajouter de l'objet apportait quelque chose à OpenDCF, j'ai donc continué le développement en procédural.
Mon cœur balance toujours entre objet ou non. La mode et les informaticiens diront toujours qu'il faut faire de l'objet, mais avec les petites contributions, et les adaptations facile qu'effectue des non informaticiens dans OpenDCF je me dit que ce choix n'est pas forcement le mauvais.
D'ailleurs, ça tourne seulement en PHP 5 car tu utilises SimpleXML, tu fais un test quelques part sur le numéro de version de PHP ?
Oui il y a un test à l'installation (test également de php_gd et php-curl qui est facultatif)
Toujours sur la maintenance, les langues ne sont pas prises en compte. La vue est attachée au code PHP. Tu sais qu'on préfère éviter

.
Meme remarque que pour le choix de l'objet.
Le code HTML maintenant. J'ai vu une balise <center>. Oula … *respire* il faudrait abuser un peu plus de CSS, ça ne fait pas de mal en règle générale

.
Je n'ai pas regardé l'accessibilité de l'application, mais j'ai vu beaucoup de tableau « mal construit » (manque des balises <th> par exemple).
Je fait valider la plupart du code en xhtml 1.1 transactionnel. Je crois que peu de site réalise ce genre de tests et la balise center n'a jamais causé d'alert ni meme de warning (pour info la page d'accueil de phpfrance contient 136 erreurs et 22 warning).
Mais appréciant les normes html et vue que la balise <center> est déconseillé, je vais au fur et à mesure des maintenance la remplacer par du css (
http://www.la-grange.net/w3c/html4.01/c ... deprecated)
Le code PHP : il faut tout protéger de A à Z. Se dire : « le client peut se suicider tout seul, ça m'est égal » ne tient pas la route. Même s'il utilise un intranet, on peut s'y connecter et tout casser. Imagine qu'il l'installe sur un extranet, il n'est plus protéger.
Les factures sont des données sensibles, très sensibles même. La sécurité est donc un point à mettre fortement en avant. C'est un argument qui n'est pas négligeable.
Il faut donc sécuriser au maximum ton application et effectuer une batterie de test.
Seul la page de login est blindé et crée une variable de session. Toutes les autres pages verifient l'existence de cette variable de session. Il faut donc au moins un login / mot de passe. A partir de ce principe j'ai considéré que l'utilisateur ne cherchera pas à accéder à des urls en modifiant manuellement les paramètres ou bien à effectuer des POST manuellement. Les formulaire sont donc uniquements tester en javascript. Cette solution à l'avantage de d'être plus agréable (mise en couleur des champs qui ont provoqué l'erreur), et plus rapide à coder (pas besoin de re-remplir les champs), mais en effet moins sécuriser.
Pour ceux à qui ca peut faire peur, essayez s'il vous plait de trouver une faille sans connaitre ni le login ni le mot de passe.
La structure de l'application : pour une raison de maintenance et de faciliter, je me serais tourné vers un MVC. Mais bon, on est dans la période
use-POO,
use-MVC,
use-Ajax, alors je ne vais pas te tanner avec ça

. Seulement, j'aime la POO, et pour un projet comme le tien, c'est extrêmement pratique. Tu peux faire évoluer la structure vers un raisonnement par module (module facture, module client etc), au lieu de tout mettre à la racine.
Meme remarque que pour l'objet

et comme tu dit j'ai l'impression qu'il y a un gros effet de mode à ce sujet, où l'ont considère que la technique est plus importante que les fonctionnalité.
J'ai vue des projets où justement la seule utilisation de la POO etait classer les méthodes dans une classe. Si on limite la puissance de la POO à cette seule utilisation, et s'il ne faut que ca pour dire que techniquement c'est un beau projet, et bien je peut franchement le dire je suis content de ne pas alourdir mon projet avec de la POO.
Le design de l'application : c'est très laid

. C'est pas méchant hein, je plaisante

, n'empêche que je trouve pas ça très attirant. Ton application doit séduire. Même le meilleur programme du monde avec une interface moche et merdique ne sera pas choisi. Donc il faut penser à l'expérience utilisateur, maniabilité de l'application etc. Une telle application sera utilisée par une bête petite secrétaire : va-t-elle y arriver ? Le vocabulaire est-il adapté ? Les erreurs sont claires et parlantes ? Ce sont des questions à se poser.
je ne m'inquiète pas des cela, lol, le retours des utilisateurs sur le forum d'OpenDCF va dans l'autre sens

Mais je prend note (Si en effet le theme que tu avait etait rouge ou bleu foncé c'est très laid, seul le bleu clair est soigné).
L'idée de l'application : pourquoi faire un fork de factux ?
Par ce que le développeur principale de factux à refuser mes contributions et ignorer mes alertes concernant de multiple faille de sécu. Dommage ... un beau gachi ...
La version de l'application : c'est marrant de voir une application passée en RC sans être testée

, c'est moi ou … ?
Pourquoi pas testé ? j'utilise OpenDCF depuis 2 ans, et certain depuis un an une vingtaine d'autre développeur utilise des version beta en production (c'est pas forcement prudent, mais ils sont avertit, et de mon coté cela forunit de bon retour d'expérience).
Cette RC1 est la par contre la première version pour laquelle je fais de la pub
Je ne peux que t'encourager sur un tel projet. Ça va t'apprendre beaucoup de chose, et c'est un très bonne exercice. Seulement, garde en mémoire qu'elle n'est pas encore parfaite et qu'il y a encore pas mal de choses à améliorer. Les TPE doivent être séduites au premier essaie, premier coup d'œil, est-ce que ça peut le faire ?
Sinon, considère ma réponse comme un résumé et surtout comme un ensemble de piste à suivre ou à étudier

.
Oh oui j'ai déjà beaucoup appris. Sutout sur le faite que trop de technique ne sert à rien si elles n'apportent pas de fonctionnalités.
Après séduire les TPE, et bien ... OpenDCF c'est avant tout pour moi que je le développe, et si certain besoin d'utilisateur sont intéressant à réaliser / ajouter et bien je prend mon clavier.
Enfin pour conclure sur la technique (car c'est surtout cela que tu as commenté), au début du développement d'OpenDCF j'ai commencé à reprendre le code pour que techniquement il soit "beau" et au bout de 6 mois de boulo je me suis rendu compte qu'il n'y avait encore aucune nouvelle fonctionnalité (alors que certain utilisateur attendait déjà beaucoup de ce fork). Je me suis vite rendu compte qu'avoir un projet en MVC, objet, un super framework et tout le reste ne sert à rien si la premiere RC met 5 ans pour arriver. Il est sure que le projet sera plus perenne à terme mais en attendant ni moi (qui suis le premier utilisateur) ni personne d'autre n'a un facturier simple et rapide d'utilisation (ce qui à fait le succes de factux), et mise à jour, amélioré et ouvert à la communauté.
Merci encore.