Bonjour à tous,
 
Je travaille dans une société dont l'activité principale est l'impression de courriers personnalisés.
Pour faire simple, nous recevons des fichiers de données (le plus souvent au format Excel, csv ou encore txt) que nous marrions à des fonds de page qui eux sont en PDF.
Ces fichiers sont structurés avec une première ligne reprenant le nom des champs et autant de lignes qu’il y a d’entrées.
 
Une grosse partie de notre tâche consiste ainsi à  
- Réceptionner le fichier de données (…)
- Concaténer les différentes tables contenues dans ce fichier (ou les différents fichiers reçus et relatif à la même opération)
Pour faire cela, nous devons au préalable « normer » les champs de ces différents fichiers pour pouvoir les regrouper dans un seul fichier.
- Remettre en forme ce fichier (Ajout de majuscules ou suppression d’espaces inutiles par exemple)
- Dédoubloner les entrées (les doublons peuvent être exacts ou approchés Ex: "Jean Dutour - Boulevard Ret" et "Jean Dutour - Bld Ret"
Au final nous obtenons un fichier "propre" qui sera couplé avec le fond de page.
 
Jusqu'à maintenant, toutes ces opérations sont faites sous Excel avec :
- Les risques de "décalage" des lignes (Nom N se retrouve à l'adresse N+1)
- La lourdeur des process (nous utilisons beaucoup les fonctions d'Excel pour nous aider mais il faut les retaper systématiquement ce qui est quand même fastidieux, surtout les jours où il y a plus de 15 fichiers !)
- L'inconvénient d'avoir des fichiers qui peuvent être encore modifiés par leur utilisateur final en cas de fausse manipulation (Il s’agit de l’opérateur qui fait le mariage du fichier Excel final avec le PDF, ceci avant de lancer les impressions)
 
Pour toutes ces raisons, nous souhaitons mettre en place une gestion de ces données via une base de données.
Nous pensons ainsi à une interface HTML et qui serait couplée avec une base MySQL. Je passe sur les autres composants de la moulinette (PHP ou Ruby, Ajax, etc…)
Cette orientation présenterait l'avantage pour nous de centraliser tout sur un même serveur.
Nous pourrions ainsi accéder aux données de n'importe quel poste doté d'un navigateur ce qui est parfois très utile pour nous.
 
Dans les grandes lignes voici ce que nous souhaiterions :
1-A l'ouverture de l'interface, un module permettrait d'importer le fichier reçu, tel quel.
Ce fichier serait stocké dans le format où il a été reçu et serait juste lié à une opération définissant le nom du client et la date de réception de ce fichier. Ceci à travers une table liant ces fichiers reçus aux opérations créées dans cette base.
Nous pourrions alors rappeler le ou les fichiers reçus à loisir.
2-Ce ou ces fichiers de données reçus (et dans ce cas correspondant à la même opération) seraient alors envoyés vers une table de la base de données en remappant leurs champs afin qu’ils correspondent à nos normes.
Une dizaine de champs types pourraient être définis.  
Ex : CIV pour la civilité - Les fichiers reçus ont presque toujours ce champ mais il peut être appelé CIVI, CIVILITE ou autres.
Pour les champs qui ne seraient pas « type », l'interface proposerait de les renommer ou de les laisser à l'identique.  
3-A partir de la table obtenue et qui serait en quelque sorte, la table des données non modifiées mais juste remises en forme, nous pourrions alors procéder aux différents traitements que nous sommes amenés à faire aujourd’hui par l’usage de fonctions sous Excel.
Dédoublonnage, suppression d’espaces inutiles dans des champs, rajout de majuscule, conversion de tous les champs CIV (civilité) ressemblant à Mademoiselle, MLE ou autres Melle en MLLE.
Ces différents traitements feraient l’objet chacun d’une requête bien spécifique qui serait lancer indépendamment.
J’ajoute qu’à ce stade, il serait souhaitable que la table entière soit affichée (un peu à la Excel) il qu’il soit possible de venir l’éditer directement dans le cas de certains traitements qui ne pourraient faire l’objet d’une requête pour une raison ou une autre.
4-Une fois tous ces traitements effectués, il resterait une nouvelle table qui sera la table finale, nettoyée et remise en forme pour la fameuse opération.
 
Pour schématiser, nous aurions  
A- Un ou plusieurs fichiers en entrée,  
B- Une table avec les données concaténées non modifiées,
C- Une dernière table correspondant aux données concaténées, remises en forme et nettoyées.
 
Que pensez-vous de ce projet et surtout de la complexité de sa mise en œuvre.
Nous n’avons pas les compétences en internes pour développer cela mais serions capable de donner un cahier des charges très précis sur ce que nous voulons (les vues, les fonctions, etc…)
 
Pensez vous que ce développement puisse faire l’objet d’un stage de fin d’étude qui serait bien sûr rémunéré correctement et même très correctement si le résultat est atteint (cette option présenterait l’avantage d’avoir le développeur sur place) ou alors faut-il passer par des développeurs chevronnés compte tenu de la complexité (si c’est le cas)
 
Pour la partie traitement sur les données, j’imagine que là il faudra vraiment passer par un pro du SQL qui fera des requêtes puissantes ?
Savez-vous s’il existe dans le commerce de telles requêtes, prêtes à être intégrées dans des applications ?
J’imagine que beaucoup d’entreprise, peut-être dans des contextes différents, on ce problème de gestion de listes de contacts provenant de plusieurs sources.
Nous sommes basés sur une petite île dans les Caraibes et je vous avoue être assez mal entouré commercialement sur ces problématiques de développement.
 
Merci d’avance pour vos retours et navré pour la longueur de ce message !

Ca ne me parrais pas horriblement compliqué a faire, si votre cahier des charge est assez précis, un étudiant ne devrai pas avoir trop de mal a vous ficeler tout ca.
Les requetes SQL elles meme ne sont pas très compliquées non plus, ca pourrais meme etre un tres bon exercice pour une ecole.
 
Ce que vous voulez faire est en effet assez courrant, le nom anglais est ETL (Extract, Transform and Load), il existe deja une serie d'outils (gratuit ou pas) qui pourrais déja vous faciliter la tache ou meme carement vous fournir une solution completement automatique.

Bonjour,
A première vue, à mon sens, cela parait tout a fait réalisable pour un stage
La seule difficultée que je vois réside dans les règles de transco à implémenter : mettre en majuscule, enlever les blancs, dédoublonner, remplacer dans certains cas mais pas d'autres ... (qui peut rapidement devenir une usine à gaz sans fin)
-> a moins que cela peut être paramétré dans l'appli directement

Merci pour vos réponses.
Je vais affiner notre cahier des charges que je soumettrai dans le forum emploi.
Bonne journée.

Comme ETL en GPL y'a Pentaho. En fait, il fait du décisionnel mais il a une partie ETL.
 
Y'a aussi Talend Open Studio.
 
Un petit article sur les ETL : http://www.osbi.fr/?p=126

Merci pour ces retours, je me rend compte grâce à vos lumière qu'il s'agira surtout d'interface une interface HTML avec une base MySQL et les modules ETL qui seront retenus.
 
Dernière question, selon vous, quelle est la compétence première à avoir pour ça, le MySQL ou le développement HTML (ce qui n'exclue pas bien sûr une maîtrise de tous ces aspects)

Quand on fait un outil en web, il faut être compétent sur XHTML, CSS, Javascript, PHP et le SQL (mysql ou un autre sgbd). Etre faible sur l'un de ces points amènera forcément des problèmes/retards/pbs de maintenance. Les pbs de maintenance sont du reste un pb récurent dans les projets faits par des stagiaires. Etant là pour se faire la main, on ne peut leur demander d'être aussi compétent que qq'un ayant plusieurs années d'expérience. Et y'a la contrainte de temps (sachant que les 2 dernières semaines, le stagiaire bosse sur son rapport). Voulant avoir une bonne note (normal!) et celle-ci étant souvent corrélée au fait de voir si le projet a abouti sur un "truc" qui marche, la qualité technique du code produit est très souvent un désastre. Le jour où l'entreprise veut faire modifier l'outil, bien souvent, faut tout recommencer car mal architecturé, pas documenté...
 
Donc, mon conseil, demander au stagiaire le dossier de conception, le manuel d'exploitation et le MUT à la fin du stage, vérifier que le code est largement commenté. Vaut mieux qu'il n'ait pas eu le temps de tout faire mais que ce qu'il a fait est documenté et tient la route (ça, c'est le plus dur à évaluer) pour permettre à un autre stagiaire, plus tard, de reprendre où ça en était resté. Eventuellement, vous pouvez proposer au stagiaire de continuer le travail après la fin du stage, en CDD, s'il en a la possibilité.